remoting_2_2_0_GA
by Thomas Diesler
HI Ron,
JBossAS-5.0 installs remoting-2.2.0.GA. The sources in CVS do however
not correspond to the binary in the repository. After further
investigation it turns out that remoting_2_2_0_GA is a branch tag in CVS
with lots of changes commited to it. Appart from this beeing higly
confusing, is there a way to get at the original sources for 2_2_0_GA?
Please restore remoting_2_2_0_GA to a propper (non branch) tag in CVS
The branch tag should be called remoting_2_2_0.
Generally, it is very bad idea to release a tagged binary and then allow
changes to be commited to that tag.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 7 months
Working on branch/jbossws-2.0
by Thomas Diesler
Folks,
today we recreated branches/jbossws-2.0 from the trunk codebase and
removed the sunri, xfire integration from it.
The QA is hosted here:
trunk: http://jbws.dyndns.org:8180/hudson/
jbossws-2.0: http://jbws.dyndns.org:8280/hudson/
Note, the difference in port!
Since we cut jbossws-2.0 a couple of weeks ago, trunk has undergone
significant structural changes because of our switch to the general WS
integration layer. These changes are not necessarily functional. Due to
these changes we needed to realign the 2.0 branch with trunk otherwise
the 2.0 code base would not be maintainable.
IMPORTANT!
You don't need to do anything if you immediately merged your changes
from jbossws-2.0 to trunk when you did it. In that case your changes are
preseved. However, if you did not merge your changes upstream because
trunk was too much of a moving target or for whatever other reason you
now need to manually merge your stuff to BOTH jbossws-2.0 and trunk.
I preserved a read-only copy of the old jbossws-2.0 code base here
https://svn.jboss.org/repos/jbossws/branches/jbossws-2.0.backup/
Darran, Magesh, David please confirm that your changes are commited
upstream. The attached svn.log should show what you have actually done.
Please remember, that SVN does not maintain a record of merges that have
been done accross branches. We therefore maintain a mergeinfo.txt file
for every branch that should contain the merge commands that have been
issued.
jbossws-2.0.0.GA is scheduled for 1-Jul-2007.
'svn merge' can now easily be used again to merge your changes upstream
to trunk. Please get back to me in case this procedure is not clear to
you.
Here again our dev rules - I'll post them to the wiki as well.
#1 Run 'ant tests-samples' before you commit
#2 Merge your stuff upstream yourself - maintain a merge record
#3 Include JIRA issue and title in SVN commit messages when applicable
#4 Fix what your broke. Hudson should tell you at most 24h later
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 7 months
[Fwd: [jbossws-commits] JBossWS SVN: r3394 - branches.]
by Darran Lofthouse
What is happening to the branch? I have just finished testing some
changes I have made ready to check in and the branch has been deleted.
Regards,
Darran Lofthouse.
-------- Forwarded Message --------
> From: jbossws-commits(a)lists.jboss.org
> Reply-To: jbossws-commits(a)lists.jboss.org
> To: jbossws-commits(a)lists.jboss.org
> Subject: [jbossws-commits] JBossWS SVN: r3394 - branches.
> Date: Sat, 02 Jun 2007 11:46:20 -0400
>
> Author: thomas.diesler(a)jboss.com
> Date: 2007-06-02 11:46:20 -0400 (Sat, 02 Jun 2007)
> New Revision: 3394
>
> Added:
> branches/jbossws-2.0.backup/
> Removed:
> branches/jbossws-2.0/
> Log:
> Create a jbossws-2.0 backup copy
>
> Copied: branches/jbossws-2.0.backup (from rev 3393, branches/jbossws-2.0)
>
> _______________________________________________
> jbossws-commits mailing list
> jbossws-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-commits
17 years, 7 months
Re: org.jboss.wsf.stack.jbws.RequestHandlerImpl and ServletRequestContext ?
by Thomas Diesler
This should be fixed
-thomas
On Fri, 2007-06-01 at 13:23 +0100, Tom Fennelly wrote:
> Hey there Thomas.
>
> I've run into a little problem and need some guidance.
>
> So I checked out and built the JBossWS 2.1 codebase yesterday evening.
> I updated the ESB code to use th new SPI. The new code looks as follows:
>
> RequestHandler requestHandler = endpoint.getRequestHandler();
> InvocationContext invocationContext = endpoint.getInvocationHandler().createInvocation().getInvocationContext();
> ByteArrayOutputStream os = new ByteArrayOutputStream();
>
> requestHandler.handleRequest(endpoint, new ByteArrayInputStream(soapMessage), os, invocationContext);
>
>
> When I run it I get a ClassCastException out of
> org.jboss.wsf.stack.jbws.RequestHandlerImpl. It's trying to cast the
> InvocationContext to a ServletRequestContext. The endpoints I'm
> attempting to invoke are standard 181 impls deployed out of the Servlet
> container, which maybe explains why the request handler is expecting a
> ServletRequestContext.
>
> Do I need to create specific Endpoint, RequestHandler etc impls? If so,
> does that mean that endpoints deployed out of the Servlet container are
> only invokable with ServletRequest, ServletResponse, ServletContext etc
> at hand?
>
> Regards,
>
> T.
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 7 months
JBossWS-2.1.0.Beta1 Released
by Thomas Diesler
Folks,
I am pleased to announce that we just released JBossWS-2.1.0.Beta1. It
is the first release based on the new general Web Service integration
layer and brings both SunRI and XFire to JBossAS.
Compatibility details are here:
http://jbws.dyndns.org:8180/hudson/view/Release%20QA/
Here a picture of the architecture (more docu to come)
http://fisheye.jboss.com/browse/JBossWS/trunk/build/build.xml?r=3397
For the first time, customers will have choice which WS stack to deploy
in JBossAS. The decission can be made based upon the stack's feature set
and performance characteristics.
JBoss added value and general advantages to this approach are for
example:
#1 Common deployment model
Standard JavaEE5 deployments + JBoss extensions work
with all supported stacks. XFire supports EJB3
endpoints for the first time and only in JBoss.
#2 Common management interface
Through the JBossWS managment console you get a common view of all
deployed endpoints
#3 Common QA
A common testsuite runs against all supported stacks.
Thirparty dependencies are resolved and QAed
http://jbws.dyndns.org:8180/hudson/
#4 Increased visibility
Currently we have ~190000 downloads per release. We bring this
visibility to the other stacks and act as a common support entity.
Users of SunRI, XFire may now bring business to JBoss
#5 Other integration advantages
For example end to end security.
We will now start the dialog with Sun and XFire and see if we can get
get good cooperation on the way.
The jbossws-2.1.0.GA release is targeted for 1-Aug-2007
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 7 months
