Hi,
Thank you for you advice. I do a small experiment. I use
ExtensibilityElement to replace TExtensibilityElementImpl. Also I
modified some codes in the cxf-api project.
It works now.
best regards,
liu
Daniel Kulp wrote:
Liu,
I think for stuff that are "simple" (basically, complex
Liu,
I think for stuff that are "simple" (basically, complexTypes with
simpleContent and simpleType object), you cannot extend
TExtensibilityElementImpl. Instead, you would need to make it implement
ExtensibilityElement interface and add the QName and required fields and such.
Dan
On
To be completely honest, I'm very confused by this. Under pretty much every
circumstance I can think of, the service objects will get the data as "String"
objects, which are aren't encoded.The service really should have no
knowledge (or need for such knowledge) of how the data was represe
On Wed July 1 2009 12:28:03 pm David Bosschaert wrote:
> What would the impact be?
There are a couple things:
1) The release managers would need to add some settings into their
settings.xml to allow them to deploy to repository.apache.org. Not a huge
deal.
2) The "mvn release:prepare; mv
Dear Dan,
Now Im facing a different problem. The Client sends SOAP Message which has
UTF-16 encoded XMLdocument. My Server's
service handler can process only UTF-8 encoded data. Naturally we can
transform UTF-16 to UTF-8 while accessing data in the handler's
Implementation.
But im looking for a so
What would the impact be?
Simply the fact that the releases are also hosted at
repository.apache.org? That would be fine with me as long as they
don't just disappear which seems to have happened to our deployed
snapshots at the moment...
David
2009/7/1 Daniel Kulp :
>
> Actually, this would apply
Hi,
I do a simple experiment about the design sugguest by Dan.
First, I use jaxb, not xjc. I think they have the principle.
The schema like this[1]:
The generated class for DeliveryModeType like this[2]:
@XmlAccessorType(XmlAcce
+1 ... go for it!
Jeff
On Jul 1, 2009, at 8:47 AM, Daniel Kulp wrote:
OK. With Maven 2.2.0 finally out, we should have a version of
Maven that
works with GPG plugin (and thus is usable for Apache releases) as
well as
provides functionality for encrypted passwords and such in
settings
Actually, this would apply to David and Glen and the other DOSGi folks as
well. Thus, their input would be good.
Dan
On Wed July 1 2009 10:47:38 am Daniel Kulp wrote:
> OK. With Maven 2.2.0 finally out, we should have a version of Maven that
> works with GPG plugin (and thus is usable for A
OK. With Maven 2.2.0 finally out, we should have a version of Maven that
works with GPG plugin (and thus is usable for Apache releases) as well as
provides functionality for encrypted passwords and such in settings.xml.
Thus, I'd like to revisit this.
Since our snapshots are already the
Sorry, my fault. I was under the illusion there were no servlet system tests at
all :-)
I turned this specific test into a negative one, given that there's another
test which tests the service listings working.
Now, /services becomes available to applications if a hide-service-list-page servlet
11 matches
Mail list logo
