Status of JBossWS Testsuite
by Darran Lofthouse
What is the current status of the JBossWS Testsuite?
At the moment there seems to be a number of WS-RM tests that take a huge
amount of time to execute and then fail. Overall I am seeing testsuite
runs of over three hours.
I really need the ability to be confident I have not broken anything
else before committing code and just running the samples is not sufficient.
Regards,
Darran Lofthouse.
16 years, 9 months
Re: [jbossws-dev] Re: Web Service Stack for EAP 5
by Mark Little
On 19 Mar 2008, at 18:42, Burr Sutter wrote:
> I'll have to say that that I don't fully agree with "good enough". :-)
Don't believe all of the hype around WS-* ;-) Having been involved
with it since 1999 and co-authored more of the specs/standards than I
care to remember, I'm fairly happy to say that with some confidence.
> However, it is very hard for me to specifically state that a
> particular feature/item "must" be addressed in a particular time
> frame. Here is why:
> - We don't have a formal way of surveying our userbase to see what
> would really be interesting & compelling for them. We have to gave
> into the proverbial crystal ball and try to back up our
> prognostications with anecdotal evidence from personal visits with
> customers, forum postings and support cases (so I added Darran on
> the CC, do double check my list of priorities below). Certainly the
> jira voting system has failed us in this area. So we lack real
> compelling and actionable data so we base things on intuition.
> - Many of the people who do ask for a specific WS-* fall in the
> "tirekicker" category. That is a US expression for someone who is
> basically a professional shopper, not a buyer (aka adopter/user),
> they love to look but they have no motivation to make a decision.
> Corporate America's IT shops are full of these kinds of people.
> There are people who have full-time jobs in product review,
> standards setting and general vendor abuse. :-) These folks are
> normally measuring the "value" for technology based on its buzzword
> compliance level, much like a Gartner or Forrester would as well.
> I'm not saying they are bad people but their job is to put often to
> keep particular technologies out of their data centers, they love to
> say "IBM is our standard, JBoss isn't on the list, unless you can
> prove X, Y & Z to me". These folks are non-coders and won't even be
> involved in the real deliverables. - Some "prospects" represent ISVs
> who often love the "best of breed" approach. They will self-
> assemble their own "platform" from various OSS projects. Obviously,
> this is not a "sweet spot" for us since we want people to use
> specific components in a specific platform so we can properly
> support & patch their platform. So I try to remove these
> recollections from how I prioritize things in my own head.
> - I have the perception that the "big vendors" have dedicated teams
> of "standards" folks who are pushing BS in the various committees to
> simply stay ahead of the open source commoditization of their
> techs. Let's face it. The big boys have lost billions to open
> source (JBoss, Tomcat, Hibernate and others), I'm fairly certain
> that they see "standards" as a competitive weapon and their sales
> staffs have been instructed to educate the userbase on this fact
> that open source can't keep up in standards & tools.
They do. Oracle get a lot of business on this fact. But we are
standards compliant. No one is compliant with all of WS-*. That is not
the point. We just need to pick the core. What we have is the core.
That is what my comment about "good enough" referred to.
>
>
> With all of that said, WS-RM & WS-Notification are asked for the
> most (beyond SOAP, WSDL, JAX-WS, what I call the basics). There is
> a belief in our userbase that they do wish to take advantage of
> these features even if they don't yet know how.
Well we need to educate them that WS-N is dead for start!
> I don't recall running into a single JBoss shop (outside of ISVs)
> who specifically moved to CXF or Metro to get this feature.
> However, I have run into several who continue to use Axis on JBoss
> for various reasons (mostly around legacy MSFT interop or simple
> comfort factor).
>
> Honestly the most actionable priorities that I feel "strongly" about
> are (granted, not are all on this particular team), listed in
> perceived priority order:
> - Dramatically better integration into the ESB
> - JBDS Tooling needs to have support for JBossWS, not just Axis,
> customers are confused by this
> - JON needs to have support for JBossWS: take what is at http://localhost:8080/jbossws
> and make sure it is available in JON, perhaps it is there but I've
> never seen it.
> - More proof of interop with .NET. At this point, I just tell
> people that if they find it is broken, get a support subscription
> and enter it as a high priority bug, we will fix it.
Agreed and that's what I said before.
> I remember Kevin W from MSFT worked his butt off at JBossWorld
> Vegas to get helloworld version of WS-Security & MTOM working with
> a .NET client to JBoss backend. It wasn't well documented, no
> examples, lots of pain on his part and he would be considered a
> very, very advanced developer, well beyond the skills of your
> typical enterprise IT developer (our typical customerbase)
Yes, I can understand that. We do not participate in interop enough.
We also do not make our endpoints public, which is something I've been
pushing for since 2005.
>
> - Security: there is a lot related to security that I've not had a
> chance to think through. It relates to JAAS, SAML, integration with
> Red Hat's "certificate server". This actually comes up often and I
> dance enough to skip the answers. :-) However, there is enough
> questioning in this area to suggest the userbase wants some nice
> examples/docs and education on the "best practices". Clearly I have
> no clue how to implement all of this but I've not dug through the
> docs, wikis & forums enough to see if someone has described how to
> tackle all of my security (encryption, authentication,
> authorization) needs. I've never seen this in JON and that is where
> it eventually needs to get to as security is not managed by the
> developers but by the administrators. - REST
> - SOA Software & Amberpoint supported
>
> So, I ask all of you this. Do the bullets above also sound like
> priorities in your own minds, therefore, we/the team, need to spend
> a few more cycles really nailing down these requirements, designs
> and roadmap which release/timeframe they'll be "proven" in? Is
> there anything that I left off that you happen to know is also a
> critical priority (that isn't just a bug fix).
Priorities for what? 2008? 2009?
Mark.
>
>
>
> Mark Little wrote:
>> Understood and I think what you've got at the moment is really good
>> enough. It's the core capabilities. Let's just make sure it's
>> interoperable and fast, and job done :-)
>>
>> Mark.
>>
>>
>> On 19 Mar 2008, at 13:11, Heiko Braun wrote:
>>
>>>
>>> Agreed. I am just saying instead looking at what the others
>>> have on their managers checklist, we should first come up with
>>> actual requirements.
>>>
>>> If we are talking about EAP 5, just write down what the stack really
>>> needs to provide and the WS team can decide on the best way to
>>> achieve
>>> this. That's at least my opinion.
>>>
>>>
>>> /Heiko
>>>
>>> On Wed, 2008-03-19 at 12:57 +0000, Mark Little wrote:
>>>> But it's not the way to go in the future.
>>>
>>
>> ----
>> Mark Little
>> mlittle(a)redhat.com
>>
>> JBoss, a Division of Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903
>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt
>> Parsons (USA) and Brendan Lane (Ireland).
>>
>
----
Mark Little
mlittle(a)redhat.com
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt
Parsons (USA) and Brendan Lane (Ireland).
16 years, 9 months
CXF Build is Broken
by Richard Opalka
Hi Folks,
I'm facing the following problem:
* I checked out
http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.4-incubator
CXF tag
* I ran mvn with clean local repository (means there's not
~/.m2/repository directory on my machine)
Using this configuration the CXF build fails because some referenced
dependency artifacts are not available
on Apache servers. Here's the error I'm getting:
* [ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.apache.geronimo.specs:geronimo-qname_1.1_spec:jar:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.geronimo.specs
-DartifactId=geronimo-qname_1.1_spec \
-Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs
-DartifactId=geronimo-qname_1.1_spec \
-Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.cxf:cxf-rt-bindings-jbi:jar:2.0.4-incubator
2) org.apache.servicemix:servicemix-jbi:jar:3.1.2
3) org.apache.geronimo.specs:geronimo-qname_1.1_spec:jar:1.1
2) org.apache.geronimo.specs:geronimo-activation_1.0.2_spec:jar:1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.geronimo.specs
-DartifactId=geronimo-activation_1.0.2_spec \
-Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs
-DartifactId=geronimo-activation_1.0.2_spec \
-Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.cxf:cxf-rt-bindings-jbi:jar:2.0.4-incubator
2) org.apache.servicemix:servicemix-jbi:jar:3.1.2
3) org.apache.geronimo.specs:geronimo-activation_1.0.2_spec:jar:1.2
----------
2 required artifacts are missing.
for artifact:
org.apache.cxf:cxf-rt-bindings-jbi:jar:2.0.4-incubator
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
*
Is there an JIRA issue associated with that problem where I could
subscribe to?
Richard
16 years, 9 months
Re: SOAP/JMS
by Thomas Diesler
Hi Mark,
Currently, a client has to use the jms API directly. On the server side
we don't generate the jms binding definition either.
Here are the related issues:
Provide JMS transport for JAX-WS client
http://jira.jboss.com/jira/browse/JBWS-670
Provide JMS Binding in generated WSDL
http://jira.jboss.com/jira/browse/JBWS-2077
cheers
-thomas
Mark Little wrote:
> Which binding definition did you use for this?
>
> Mark.
>
> ----
> Mark Little
> mlittle(a)redhat.com
>
> JBoss, a Division of Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Brendan Lane (Ireland).
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 9 months
@SecurityDomain annotation causing failures
by Alessio Soldano
Hi Folks,
I spent some time understanding why the following two tests of JBWS-1988
and JBWS-1991 are failing for AS5 only:
http://jbws.dyndns.org:8180/hudson/job/Native-Core-AS-5.0.0/lastBuild/tes...
http://jbws.dyndns.org:8180/hudson/job/Native-Core-AS-5.0.0/lastBuild/tes...
On AS 5 the @SecurityDomain annotation is not found by the ejb3 aop
interceptor (Ejb3AuthenticationInterceptorv2) and thus the
authentication doesn't fail even if wrong user/pwd is used. The reason
for this is that the AS5 interceptor looks for
org.jboss.ejb3.annotation.SecurityDomain while the AS 4.2 interceptor
looks for org.jboss.annotation.security.SecurityDomain that is the
annotation we use to use in our endpoints.
Do you think we should consider this as an ejb3 issue and thus write it
to the jbossas jira? Honestly I don't like having 2 different
annotations to do the same thing on different containers (using the new
annotation the tests run fine on AS5), but I'm not aware of the reasons
that drove to the new annotation in AS5.
Thanks
Alessio
16 years, 9 months
[Design of JBoss Web Services] - Re: JBossWS 3.0.1 Release Issues
by richard.opalka＠jboss.com
The following is copy/paste from our current SPI version properties. Are the following thirdparty dependencies still up2date?
# Thirdparty library versions
| apache-ant=1.6.5
| dom4j=1.6.1
| gnu-getopt=1.0.10
| jboss-common-core=2.0.2.GA
| jboss-common-logging-log4j=2.0.2.GA
| jboss-common-logging-spi=2.0.2.GA
| jboss-javaee=5.0.0-SNAPSHOT
| jboss-jbossxb=1.0.0.GA-brew
| jboss-microcontainer=2.0.0.Beta3
| sun-jaf=1.1
| sun-jaxb=2.1.4
| sun-jaxrpc=1.1
| sun-jaxws=2.1.1
| sun-servlet=2.5
| junit=3.8.1
I'm asking because we're doing QA against AS Beta 4 and I see the following MC artifacts at the moment:
[/home/opalka][/opt/svn/jboss.local.repository/jboss/microcontainer]>svn list https://svn.jboss.org/repos/repository.jboss.org/jboss/microcontainer
| 0.9.1/
| 0.9.2/
| 0.9.3/
| 0.9.4/
| 0.9.5/
| 1.0.0/
| 1.0.1/
| 1.0.2/
| 2.0.0.Beta/
| 2.0.0.Beta10/
| 2.0.0.Beta10.1/
| 2.0.0.Beta11/
| 2.0.0.Beta2/
| 2.0.0.Beta3/
| 2.0.0.Beta3.1/
| 2.0.0.Beta4/
| 2.0.0.Beta5/
| 2.0.0.Beta6/
| 2.0.0.Beta7/
| 2.0.0.Beta8/
| 2.0.0.Beta9/
| snapshot/
| snapshot-classloader/
| snapshot-metadata/
| snapshot-temp/
|
I would say we should refer to 2.0.0.Beta4 in version properties don't we?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138445#4138445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138445
16 years, 9 months
