Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2005-06-22 18:45:37
|
Even for the container solution, it would seem that we should support a more java bean approach via a jbxb:class container attribute: | <xs:element name="module-option"> | <xs:complexType mixed="true"> | <xsd:annotation> | <xsd:appinfo> | <jbxb:class container="org.jboss.test.xml.mbeanserver.ModuleOptionContainer" | accessor="instantiate"/> | </xsd:appinfo> | </xsd:annotation> | <xs:sequence> | <xs:any minOccurs="0" maxOccurs="1" namespace="##other" /> | </xs:sequence> | <xs:attribute name="name" use="required" type="xs:string"/> | </xs:complexType> | </xs:element> | where ModuleOptionContainer would not implement any specific interface. Its has a non-arg ctor as is treated the same as any other class except that on completion of the element its associated with, the jbossxb layer would invoke the method referenced by the accessor to retrieve the actual object binding. All this avoids is having to deal with the explicit handling of attributes and elements. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882413#3882413 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882413 |
|
From: <sco...@jb...> - 2005-06-22 18:32:43
|
The current workaround for dealing with objects with non-default ctors is to use a container implementing org.jboss.xml.binding.GenericValueContainer. For the ModuleOption:
| package org.jboss.test.xml.mbeanserver;
|
| import javax.xml.namespace.QName;
| import org.jboss.xml.binding.GenericValueContainer;
|
| /**
| * ModuleOption declares a constructor that takes name as a parameter while the value should be set
| * with the setter. This use-case is not supported out-of-the-box. So, we use this container.
| *
| * @author <a href="mailto:al...@jb...">Alexey Loubyansky</a>
| * @version <tt>$Revision: 1.1 $</tt>
| */
| public class ModuleOptionContainer
| implements GenericValueContainer
| {
| private String name;
| private Object value;
|
| public void addChild(QName name, Object value)
| {
| if("name".equals(name.getLocalPart()))
| {
| this.name = (String)value;
| }
| else
| {
| this.value = value;
| }
| }
|
| public Object instantiate()
| {
| ModuleOption option = new ModuleOption(name);
| option.setValue(value);
| return option;
| }
| }
|
|
I guess both attributes and elements are treated the same and passed to the addChild method. The associated xsd fragment is:
| <xs:element name="module-option">
| <xs:complexType mixed="true">
| <xsd:annotation>
| <xsd:appinfo>
| <!-- ModuleOption declares a constructor that takes name as a parameter
| while the value should be set with the setter.
| This use-case is not supported out-of-the-box. So, we use this container. -->
| <jbxb:class impl="org.jboss.test.xml.mbeanserver.ModuleOptionContainer"/>
| </xsd:appinfo>
| </xsd:annotation>
| <xs:sequence>
| <xs:any minOccurs="0" maxOccurs="1" namespace="##other" />
| </xs:sequence>
| <xs:attribute name="name" use="required" type="xs:string"/>
| </xs:complexType>
| </xs:element>
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882411#3882411
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882411
|
|
From: <sco...@jb...> - 2005-06-22 18:26:28
|
http://jira.jboss.com/jira/browse/JBXB-28 I created this issue to request support for non-default ctors for elements as its a common scenario for an existing object model to require that the immutable properties be passed in via the ctor. An example from the login-config.xml parsing is this ModuleOption with a read-only name: | package org.jboss.test.xml.mbeanserver; | | public class ModuleOption | { | String name; | Object value = ""; | | ModuleOption(String name) | { | this.name = name; | } | | String getName() | { | return name; | } | Object getValue() | { | return value; | } | void setValue(Object value) | { | this.value = value; | } | } | The ModuleOption is mapped from a module-option element where the ctor arg is specified as an attribute on the element. | <jaas:module-option name="unauthenticatedIdentity"> | guest | </jaas:module-option> | This is the most common usecase I have. I suppose the arguments could also be child elements, but this is likely a very detyped schema or one with multiple namespaces. The only real issue I see is how to convert the attribute string to the correct type for the ctor argument. Using a converter similar to the existing jbxb:value unmarshalMethod would be the simplest. If the attribute has a type mapping in the xsd that could also be used? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882410#3882410 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882410 |
|
From: <tom...@jb...> - 2005-06-22 17:45:46
|
The JBossRemoting 1.2.0 release is now available. Some of the new features include:
* SSL Support
* Support for HTTP/HTTPS proxy and basic authentication (direct and via proxy)
* Sending of input streams
* Servlet based invoker
* Pluggable custom socket factories
* Pluggable thread pools
* Connection failure detection (even on idle clients)
* Persistence of pull callback messages
This release includes many enhancements to current features and some bug fixes as well. See release notes for further details.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882407#3882407
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882407
|
|
From: mikezzz <nu...@jb...> - 2005-06-22 16:33:37
|
http://www.artima.com/lejava/articles/contentrepository.html JSR 170 is a recently verified standard for Java Content Repositories. Looking at the specification, the hierachical model is one that seems to match well with the concept of Folders->Messages->Body->Body Parts structure that JBoss mail uses. Would it be stupid to suggest that we partially implement (via hibernate) this spec and use this structure for managing the persistent data within JBoss Mail. Some of the pros: - Natural match with our problem domain (hierachical data structure). - Static Database schema. Once the JCR implementation stablises the database schema is much less likely to change (no new columns when an class definition changes). - Versioning could be used to handle messages arriving while a folder's messages are being read. - Security can be encapsulated within the JCR. Some cons: - There are a couple of areas where the API doesn't quite to enough, one example is the Value class does not have a getSize() method (very important for large objects - mail bodies). - Would more tightly integrate the folder & store implemenations - is this a bad thing?? With regards to planning, I would say this should occur along with the IMAP implemenation as the Folder implemenation will need to change when we introduce IMAP anyway. Initially we would not imlpement the whole spec, only enough to get what we need. I am interesting in hearing other peoples take on this idea. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882400#3882400 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882400 |
|
From: <sco...@jb...> - 2005-06-22 15:17:56
|
I have checked in what I last head as the jboss-4.0/build/build-thirdparty.xml script. There should be no need to update the build.xml scripts to test this out. Using the jboss-4.0.x alias which is equivalent to the jboss-4.0 without the thirdparty directory strucutre, one should be able to do: | cvs co -r Branch_4_0 jboss-4.0.x | cd jboss-4.0/build | ant -f buildfile build-thirdparty.xml | ant | The libraries.ent in this workspace should simply be replaced: | <target name="generate-lib-file" depends="synchronize"> | <gen-lib-file filename="libraries.ent" path="../tools/etc/buildmagic/" /> | </target> | Once this is working we can update the build files and move the libraries.* files to the thirdparty structure where it belongs as a thirdparty artifact. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882389#3882389 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882389 |
|
From: <rya...@jb...> - 2005-06-22 14:59:19
|
The only problem I see is that the properties and classpaths produced by this script will be the new ones based on the repository, and will therefore be slightly different (ie, apache-logging instead of apache-commons). So the existing libraries.ent and each module's build.xml classpaths need to be updated to work with these slightly different classpaths. Scott, if you could commit the work you have for the toplevel build, we can work on updating the the libraries.ent and module build.xml's to be compatible with the generatedLibraries.ent. Just to be clear, we won't be changing anything in /thirdparty. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882384#3882384 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882384 |
|
From: <jas...@jb...> - 2005-06-22 13:44:19
|
I think option 2 introduces the possibility of a name collision since you would be dealling with only one target namespace. -Jason View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882367#3882367 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882367 |
|
From: <dim...@jb...> - 2005-06-22 13:19:28
|
I was thinking of a simple binding that would let you get/set the comments before the beggining of an element (and after the end of the previous element).
| ...
| </prev-element>
|
| <!-- comment1 -->
| <!-- comment2 -->
| <element1>
| ...
| </element1>
|
|
| public class PojoForElement1
| {
| String[] getComments()
| void setComments(String[])
| ...
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882364#3882364
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882364
|
|
From: <ale...@jb...> - 2005-06-22 13:08:53
|
"Scott" wrote : Are you saying there should be treatment of comments as text to map onto an object the same as a text element? Yes. "Scott" wrote : The problem is how is there a meaningful indexing of the comments to the java objects? I don't know any rule for that. But there are use-cases, e.g. if there is no element 'description' the text could appear in comments instead and be bound to a field 'description' in a class. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882361#3882361 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882361 |
|
From: <sco...@jb...> - 2005-06-22 12:50:51
|
I guess I don't understand the difference between mapping to a java field and a java comment. Are you saying there should be treatment of comments as text to map onto an object the same as a text element? The problem is how is there a meaningful indexing of the comments to the java objects? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882359#3882359 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882359 |
|
From: neil_g_avery <nu...@jb...> - 2005-06-22 10:48:59
|
Hi All, Is it possible to have a running application, and then hotdeploy a jar which has an associated aop.xml to be applied? I imagine this may be tricky as it would require reweaving of already loaded classes and only work on the those classes that are 'prepared'. However, what it the new deployment was only applied to a jar, or set of jars not deployed in the container? If this is not possible, would a sensible alternative be to go offline; prepare (aopc) the jar, rebundle and deploy that? Would this approach cause problems? Regards Neil. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882349#3882349 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882349 |
|
From: <ale...@jb...> - 2005-06-22 10:34:54
|
It should be possible both ways. The first option needs investigation. The second should work with the current code. I think, I will investigate the first one anyway the next quarter as part of http://jira.jboss.com/jira/browse/JBXB-23. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882346#3882346 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882346 |
|
From: <ale...@jb...> - 2005-06-22 10:25:50
|
"sco...@jb..." wrote : Can the existing org.jboss.util.xml.JBossEntityResolver be used/updated for this? I think so. It could implement SchemaBindingResolver or an impl of SchemaBindingResolver could delegate to it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882344#3882344 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882344 |
|
From: <dim...@jb...> - 2005-06-22 09:54:34
|
Yes, just a simple mapping of xml comments to fields. If this could be optionally mapped to annotations, thats fine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882342#3882342 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882342 |
|
From: <ale...@jb...> - 2005-06-22 09:33:50
|
I think, Dimitris meant to bind comments from XML content to, e.g., Java fields, not to Java comments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882339#3882339 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882339 |
|
From: <tho...@jb...> - 2005-06-22 08:02:32
|
Hi folks, A type maybe defined in multiple schemas. To illustrate this, I use the example from the admin devel test. | <schema targetNamespace="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel" xmlns:tns="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://org.jboss.webservice/example/types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema"> | <import namespace="http://org.jboss.webservice/example/types"/> | <complexType name="HelloObjArray"> | <sequence> | <element name="value" type="ns2:HelloObj" nillable="true" minOccurs="0" maxOccurs="unbounded"/> | </sequence> | </complexType> | </schema> | | <schema targetNamespace="http://org.jboss.webservice/example/types" xmlns:tns="http://org.jboss.webservice/example/types" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema"> | <import namespace="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel"/> | <complexType name="HelloObj"> | <sequence> | <element name="msg" type="string" nillable="true"/> | </sequence> | </complexType> | </schema> | Currently when marshalling the HelloObjArray type, we give the marshalling layer an URL that points to the schema of the namespace associated with that type. Marshalling fails with | Caused by: java.lang.IllegalStateException: Failed to marshal wildcard. Class mapping not found for org.jboss.test.webservice.admindevel.HelloObj@940b84 | at org.jboss.xml.binding.XercesXsMarshaller.marshalWildcard(XercesXsMarshaller.java:491) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:465) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroupSequence(XercesXsMarshaller.java:583) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroup(XercesXsMarshaller.java:538) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:462) | at org.jboss.xml.binding.XercesXsMarshaller.marshalComplexType(XercesXsMarshaller.java:449) | at org.jboss.xml.binding.XercesXsMarshaller.marshalElementType(XercesXsMarshaller.java:354) | at org.jboss.xml.binding.XercesXsMarshaller.marshalElement(XercesXsMarshaller.java:320) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:469) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroupSequence(XercesXsMarshaller.java:583) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroup(XercesXsMarshaller.java:538) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:462) | at org.jboss.xml.binding.XercesXsMarshaller.marshalComplexType(XercesXsMarshaller.java:449) | at org.jboss.xml.binding.XercesXsMarshaller.marshallInternal(XercesXsMarshaller.java:176) | at org.jboss.xml.binding.XercesXsMarshaller.marshal(XercesXsMarshaller.java:141) | at org.jboss.ws.jaxb.JAXBMarshallerImpl.marshal(JAXBMarshallerImpl.java:89) I can see two potential solutions to that 1) We change the contract with the marshalling layer, such that it will be given the complete set of schema definitions 2) The WS layer rewrites the schema set to a single composite schema definition. This has been assigned to http://jira.jboss.org/jira/browse/JBWS-268 What are your thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882329#3882329 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882329 |
|
From: <tho...@jb...> - 2005-06-22 08:01:51
|
Hi folks, A type maybe defined in multiple schemas. To illustrate this, I use the example from the admin devel test. | <schema targetNamespace="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel" xmlns:tns="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://org.jboss.webservice/example/types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema"> | <import namespace="http://org.jboss.webservice/example/types"/> | <complexType name="HelloObjArray"> | <sequence> | <element name="value" type="ns2:HelloObj" nillable="true" minOccurs="0" maxOccurs="unbounded"/> | </sequence> | </complexType> | </schema> | | <schema targetNamespace="http://org.jboss.webservice/example/types" xmlns:tns="http://org.jboss.webservice/example/types" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema"> | <import namespace="http://org.jboss.webservice/example/types/arrays/org/jboss/test/webservice/admindevel"/> | <complexType name="HelloObj"> | <sequence> | <element name="msg" type="string" nillable="true"/> | </sequence> | </complexType> | </schema> | Currently when marshalling the HelloObjArray type, we give the marshalling layer an URL that points to the schema of the namespace associated with that type. Marshalling fails with | Caused by: java.lang.IllegalStateException: Failed to marshal wildcard. Class mapping not found for org.jboss.test.webservice.admindevel.HelloObj@940b84 | at org.jboss.xml.binding.XercesXsMarshaller.marshalWildcard(XercesXsMarshaller.java:491) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:465) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroupSequence(XercesXsMarshaller.java:583) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroup(XercesXsMarshaller.java:538) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:462) | at org.jboss.xml.binding.XercesXsMarshaller.marshalComplexType(XercesXsMarshaller.java:449) | at org.jboss.xml.binding.XercesXsMarshaller.marshalElementType(XercesXsMarshaller.java:354) | at org.jboss.xml.binding.XercesXsMarshaller.marshalElement(XercesXsMarshaller.java:320) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:469) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroupSequence(XercesXsMarshaller.java:583) | at org.jboss.xml.binding.XercesXsMarshaller.marshalModelGroup(XercesXsMarshaller.java:538) | at org.jboss.xml.binding.XercesXsMarshaller.marshalParticle(XercesXsMarshaller.java:462) | at org.jboss.xml.binding.XercesXsMarshaller.marshalComplexType(XercesXsMarshaller.java:449) | at org.jboss.xml.binding.XercesXsMarshaller.marshallInternal(XercesXsMarshaller.java:176) | at org.jboss.xml.binding.XercesXsMarshaller.marshal(XercesXsMarshaller.java:141) | at org.jboss.ws.jaxb.JAXBMarshallerImpl.marshal(JAXBMarshallerImpl.java:89) I can see two potential solutions to that 1) We change the contract with the marshalling layer, such that it will be given the complete set of schema definitions 2) The WS layer rewrites the schema set to a single composite schema definition. This has been assigned to http://jira.jboss.org/jira/browse/JBWS-268 What are your thought? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882327#3882327 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882327 |
|
From: ravimandari <nu...@jb...> - 2005-06-22 04:57:43
|
Generating artifacts that involve attachments with the wscompile tool is not very straightforward. Even though WS-I Basic Profile 1.0 (Part of J2EE 1.4) does not endorse attachments, JBossWS tools should provide support for attachments in a intuitive and consistent way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882316#3882316 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882316 |
|
From: ravimandari <nu...@jb...> - 2005-06-22 04:57:42
|
Generating artifacts that involve attachments with the wscompile tool is not very straightforward. Even though WS-I Basic Profile 1.0 (Part of J2EE 1.4) does not endorse attachments, JBossWS tools should provide support for attachments in a intuitive and consistent way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882315#3882315 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882315 |
|
From: <ani...@jb...> - 2005-06-22 04:40:31
|
Generating artifacts that involve attachments with the wscompile tool is not very straightforward. Even though WS-I Basic Profile 1.0 (Part of J2EE 1.4) does not endorse attachments, JBossWS tools should provide support for attachments in a intuitive and consistent way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882314#3882314 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882314 |
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:35:21
|
Some of the hardcoded instances of localhost in the testsuite can be replaced by reusing a few methods in JbossTestClusteredServices.java
Should these methods (example : getNamingURL(), getHttpURL() ) be pulled up into JBossTestServices.java?
Consider for example the use of getHttpURL() in org.jboss.test.webservice.samples.ServerSideJSETestCase:
URL url = new URL("http://localhost:8080/ws4ee-samples-server-jse/Organization?wsdl");
Here I could say something like :
URL url = new URL(getHttpURL(0) + "/ws4ee-samples-server-jse/Organization?wsdl");
where getHttpURL(0) will give me a url consisting of node0 instead of localhost.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882297#3882297
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882297
|
|
From: <ad...@jb...> - 2005-06-21 22:25:45
|
The jboss-client.xml are parsed using the MetaData classes.
These already perform the system property replacement so you should use
| ${jbosstest.server.host:localhost}
|
In the code, it should be using JBossTestCase.getServerHost()
although I don't believe there is an equivalent for serverside processing.
I can't comment on the others without looking at them.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882296#3882296
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882296
|
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:17:34
|
the following are files which were changed in /testsuite/ to accomodate for node0 : build.xml imports/test-jars.xml imports/code-generation.xml imports/server-config.xml src/resources/cosnaming.jndi.properties src/resources/iiop.jndi.properties src/resources/jndi.properties src/resources/log4j.xml src/resources/aop/META-INF/jboss-service.xml src/resources/aop/invocationlog/META-INF/jboss-service.xml src/resources/cluster/http/cluster-bindings.xml src/resources/isolation/a/ejb/META-INF/jboss.xml src/resources/jca/autocommit/hsqldb-singleconnection-ds.xml src/resources/jca/ha/test-ha-ds.xml src/resources/jca/inflow/META-INF/ra.xml src/resources/jca/inflowmdb/META-INF/ejb-jar.xml src/resources/jca/jdbc/testdriver-ds.xml src/resources/jca/jdbc/META-INF/jboss-service.xml src/resources/naming/jar/META-INF/jboss.xml src/resources/security-srp/service-inf/jboss-service.xml src/resources/test-configs/webservice-ssl/deploy/jbossweb-tomcat55.sar/server.xml src/resources/testbeancluster/cif-ds.xml src/resources/web/SecuredDD.xml src/resources/web/UnsecuredDD.xml src/resources/webservice/admindevel/META-INF/jboss-client.xml src/resources/webservice/attachment/META-INF/jboss-client.xml src/resources/webservice/encstyle/document/jboss-client.xml src/resources/webservice/encstyle/rpc/jboss-client.xml src/resources/webservice/exception/META-INF/jboss-client.xml src/resources/webservice/header/META-INF/jboss-client.xml src/resources/webservice/jbws124/META-INF/jboss-client.xml src/resources/webservice/jbws153/META-INF/jboss-client.xml src/resources/webservice/jbws163/META-INF/jboss-client.xml src/resources/webservice/jbws165/META-INF/jboss-client.xml src/resources/webservice/jbws168/META-INF/jboss-client.xml src/resources/webservice/jbws217/META-INF/jboss-client.xml src/resources/webservice/jbws68/META-INF/jboss-client.xml src/resources/webservice/jbws70/META-INF/jboss-client.xml src/resources/webservice/jbws71/META-INF/jboss-client.xml src/resources/webservice/jbws79/META-INF/jboss-client.xml src/resources/webservice/jbws82/META-INF/jboss-client.xml src/resources/webservice/jbws83/META-INF/jboss-client.xml src/resources/webservice/jbws84/META-INF/jboss-client.xml src/resources/webservice/marshalltest-doclit/META-INF/jboss-client.xml src/resources/webservice/marshalltest-rpcenc/META-INF/jboss-client.xml src/resources/webservice/marshalltest-rpclit/META-INF/jboss-client.xml src/resources/webservice/message/META-INF/jboss-client.xml src/resources/webservice/samples/client-appl/config.xml src/resources/webservice/samples/client-appl/META-INF/jboss-client.xml src/resources/webservice/samples/client-ejb/META-INF/jboss.xml src/resources/webservice/samples/client-web/WEB-INF/jboss-web.xml src/resources/webservice/samples2/doclit/config-client.xml src/resources/webservice/samples2/doclit/jboss-client.xml src/resources/webservice/samples2/rpclit/jboss-client.xml View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882295#3882295 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882295 |
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:14:54
|
IP address parameterization in testsuite http://jira.jboss.com/jira/browse/JBAS-1864 The IP address parameterization in the JBoss testsuite is a modification which will allow the testsuite to run off any IP instead of binding exclusively to localhost. Without these modifications the testsuite runs its tests only on localhost and will only allow one person on a particular machine to run the testsuite (running multiple testsuites will cause conflicts). With these modifications in place, multiple testsuites can be run on the same machine. Here is the core modification: I applied a Filterset on the NODE_0 token for the src/resources directory, replacing the token with the ${node0} property. The files containing the token are .xml and .properties files. The chunk of code is as follows: | <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}"> | <fileset dir="${source.resources}"> | <include name="**/*.xml"/> | <include name="**/*.properties"/> | </fileset> | <filterset> | <filter token="NODE_0" value="${node0}"/> | </filterset> | </copy> | <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}"> | <fileset dir="${source.resources}"> | <exclude name="**/*.xml"/> | <exclude name="**/*.properties"/> | </fileset> | </copy> | The ${node0} property can be instantiated as follows: Example : $ build -Dnode0=192.168.xxx.xxx tests For now it is not advised to run with node0 having a value other than localhost because localhost is still hardcoded in several portions of the testsuite .java files. That is still Work in Progress. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882294#3882294 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882294 |
1965 messages has been excluded from this view by a project administrator.
