Re: Error in full build on JAX-RS Frontend
Hi Christian
Perfect - thanks for taking care of it.
Cheers, Sergey
Hi Sergey,
I have simply added the locale. It works for me now:
Date serverDate = new SimpleDateFormat("EEE, dd MMM HH:mm:ss zzz",
Locale.ENGLISH)
.parse("Sun, 29 Oct 1994 19:43:31 GMT");
Greetings
Christian
Sergey Beryozkin schrieb:
Hi
I am just trying a sucessful full build before commiting the next
changes on JMS Transport.
On JAX-RS I am getting the following error. Any ideas what is going
wrong?
Could it have to do with my german language settings?
I'm not sure. Can you please try to update 'Sat' and 'Oct' in
"Sat, 29 Oct 1994 19:43:31 GMT"
(and possibly GMT ? ) with German language equivalents and see what
happens ?
May be this test needs to be updated such that the dates are not
hardcoded. If it blocks you then please
disable it and create a JIRA and I'll look into it when I start
completing JAXRS Request implementation.
Cheers, Sergey
--
Christian Schneider
---
http://www.liquid-reality.de
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [DOSGi] Patch for the first portion of CXF-1836
Thanks David, Just applied the patch. Cheers, Eoghan David Bosschaert wrote: Hi all, I've attached a patch that implements the first part of https://issues.apache.org/jira/browse/CXF-1836 to this bug. New unit tests are included too. Would greatly appreciate if someone could apply the patch. Thanks, David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
[DOSGi] patch for second part of CXF-1836
Hi all, I've attached a patch with the implementation of the DistributionProvider.getRemoteServices() API to https://issues.apache.org/jira/browse/CXF-1836 New unit tests included too. Small changes - frequent commits :) If larger patches are preferred, let me know! Thanks, David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [DOSGi] patch for second part of CXF-1836
Now applied, thanks ... /Eoghan David Bosschaert wrote: Hi all, I've attached a patch with the implementation of the DistributionProvider.getRemoteServices() API to https://issues.apache.org/jira/browse/CXF-1836 New unit tests included too. Small changes - frequent commits :) If larger patches are preferred, let me know! Thanks, David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: aegis JaxbTypeTest
Hi Benson,
Thanks for checking this out. Just to clarify, do you think the test
should be checking that its an instance of StringType in both places, or do
you think the wrong type is being returned (i.e. it should be a
CustomStringType in both cases)?
Cheers,
Peter
On Wed, Oct 01, 2008 at 05:57:55PM -0400, Benson Margulies wrote:
> I think I agree with you. I'm in no position to test with the IBM JDK. Could
> you tack a patch onto a JIRA and I'll apply it.
>
> On Mon, Sep 29, 2008 at 7:47 AM, Benson Margulies <[EMAIL PROTECTED]>wrote:
>
> > It may take me a day or two to get to this, but I will.
> >
> >
> > On Sun, Sep 28, 2008 at 10:52 PM, Peter Jones <[EMAIL PROTECTED]>wrote:
> >
> >>
> >> Hi there,
> >>
> >> Think there's a small discrepancy in the rt/databinding/aegis
> >> JaxbTypeTest.
> >> Note the type which is checked for when the element QName is
> >> "elementProperty" in the two checks below:
> >>
> >>AnnotatedTypeInfo info = new AnnotatedTypeInfo(tm, JaxbBean1.class,
> >>"urn:foo", new TypeCreationOptions());
> >>...
> >>QName element = (QName)elements.next();
> >>...
> >>Type custom = info.getType(element);
> >>if ("bogusProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else if ("elementProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof CustomStringType);
> >>} else {
> >>fail("Unexpected element name: " + element.getLocalPart());
> >>}
> >>element = (QName)elements.next();
> >>...
> >>custom = info.getType(element);
> >>if ("bogusProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else if ("elementProperty".equals(element.getLocalPart())) {
> >>assertTrue(custom instanceof StringType);
> >>} else {
> >>fail("Unexpected element name: " + element.getLocalPart());
> >>}
> >>
> >> If the "elementProperty" is the first QName, we check that the type is an
> >> instance of CustomStringType, but if its the second Qname we check that
> >> its an instance of StringType.
> >>
> >> This is the annotation in the JaxbBean1 class:
> >>
> >>@XmlElement(type = CustomStringType.class)
> >>public String getElementProperty() {
> >>
> >> Would that suggest the type should be a CustomStringType? In the test,
> >> it's
> >> always a StringType.
> >>
> >> The test passes with the sun jdk as "elementProperty" is always the second
> >> QName returned, but if you run this test with the ibm jdk, it fails since
> >> "elementProperty" is the first QName returned.
> >>
> >> If the test is wrong and it should check for StringType both times, fair
> >> enough, otherwise, I can file a jira. Let me know if you have any
> >> thoughts.
> >>
> >> Cheers,
> >> Peter
--
Peter Jones
Progress Software
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
Re: aegis JaxbTypeTest
The annotation seems to me to call for the custom type both times.
On Thu, Oct 2, 2008 at 9:16 AM, Peter Jones <[EMAIL PROTECTED]> wrote:
>
> Hi Benson,
>
> Thanks for checking this out. Just to clarify, do you think the test
> should be checking that its an instance of StringType in both places, or do
> you think the wrong type is being returned (i.e. it should be a
> CustomStringType in both cases)?
>
> Cheers,
> Peter
>
> On Wed, Oct 01, 2008 at 05:57:55PM -0400, Benson Margulies wrote:
> > I think I agree with you. I'm in no position to test with the IBM JDK.
> Could
> > you tack a patch onto a JIRA and I'll apply it.
> >
> > On Mon, Sep 29, 2008 at 7:47 AM, Benson Margulies <[EMAIL PROTECTED]
> >wrote:
> >
> > > It may take me a day or two to get to this, but I will.
> > >
> > >
> > > On Sun, Sep 28, 2008 at 10:52 PM, Peter Jones <[EMAIL PROTECTED]
> >wrote:
> > >
> > >>
> > >> Hi there,
> > >>
> > >> Think there's a small discrepancy in the rt/databinding/aegis
> > >> JaxbTypeTest.
> > >> Note the type which is checked for when the element QName is
> > >> "elementProperty" in the two checks below:
> > >>
> > >>AnnotatedTypeInfo info = new AnnotatedTypeInfo(tm, JaxbBean1.class,
> > >>"urn:foo", new TypeCreationOptions());
> > >>...
> > >>QName element = (QName)elements.next();
> > >>...
> > >>Type custom = info.getType(element);
> > >>if ("bogusProperty".equals(element.getLocalPart())) {
> > >>assertTrue(custom instanceof StringType);
> > >>} else if ("elementProperty".equals(element.getLocalPart())) {
> > >>assertTrue(custom instanceof CustomStringType);
> > >>} else {
> > >>fail("Unexpected element name: " + element.getLocalPart());
> > >>}
> > >>element = (QName)elements.next();
> > >>...
> > >>custom = info.getType(element);
> > >>if ("bogusProperty".equals(element.getLocalPart())) {
> > >>assertTrue(custom instanceof StringType);
> > >>} else if ("elementProperty".equals(element.getLocalPart())) {
> > >>assertTrue(custom instanceof StringType);
> > >>} else {
> > >>fail("Unexpected element name: " + element.getLocalPart());
> > >>}
> > >>
> > >> If the "elementProperty" is the first QName, we check that the type is
> an
> > >> instance of CustomStringType, but if its the second Qname we check
> that
> > >> its an instance of StringType.
> > >>
> > >> This is the annotation in the JaxbBean1 class:
> > >>
> > >>@XmlElement(type = CustomStringType.class)
> > >>public String getElementProperty() {
> > >>
> > >> Would that suggest the type should be a CustomStringType? In the
> test,
> > >> it's
> > >> always a StringType.
> > >>
> > >> The test passes with the sun jdk as "elementProperty" is always the
> second
> > >> QName returned, but if you run this test with the ibm jdk, it fails
> since
> > >> "elementProperty" is the first QName returned.
> > >>
> > >> If the test is wrong and it should check for StringType both times,
> fair
> > >> enough, otherwise, I can file a jira. Let me know if you have any
> > >> thoughts.
> > >>
> > >> Cheers,
> > >> Peter
>
> --
> Peter Jones
> Progress Software
> E-Mail: mailto:[EMAIL PROTECTED]
> Tel: 709-738-3725 x321 | Fax: 709-738-3745
> 570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
>
Release manager for 2.1.3 and/or 2.0.9.....
We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases. It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2. We have 33 issues resolved for 2.0.9, and 38 for 2.1.3. Thus, we probably should consider doing some releases shortly. HOWEVER, my hard drive crashed this week and part of recovering from that, I kind of realized that someone else really should try doing a release to make sure the knowledge is spread out a bit and isn't all bottled up in my head.Thus, I'd like to ask for volunteers for doing the releases. If no one jumps up, I'll be happy to do it, but it would definitely be good to get someone else involved. Requirements: 1) The release process is MUCH easier and more reliable on a Linux or OSX box. Things like gpg and ssh/scp "just work". If someone want to try Windows, I'm not sure how much I can help. 2) gpg installed and a gpg key generated and available in the public key servers. Ideally, it would be signed by other apache folks, but that's not a requirment. Anyone near Boston, we could meet for lunch and sign keys if you want. 3) Time - before building the release, you need a few hours to review release notes, notice/license files, rat reports, etc Post release, there is syncing to the maven repo, updating confluence, some JIRA admin things, etc Basically, a few hours ahead of the build, an hour to build, three days for the vote, and a few hours afterword. Anyway, if anyone is interested, speak up. I'd be happy to look over your virtual shoulder while you do the stuff to make sure it's all done right. Not a problem. Thanks! -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Status of simple front end
Given Dan's message today to a user, I want to toss out the possibility of deprecating the entire Simple front end.
Re: Status of simple front end
I'm passionately neutral. Few things are more deep-felt than my vote of zero on this matter. Glen Benson Margulies-4 wrote: > > Given Dan's message today to a user, I want to toss out the possibility of > deprecating the entire Simple front end. > -- View this message in context: http://www.nabble.com/Status-of-simple-front-end-tp19785030p19786266.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Status of simple front end
Glen, I am somewhat puzzled by your position. You put a lot of work into explaining CXF to people. The existence of the simple front end is one more thing to explain. I just fielded a JIRA from someone who had managed to combine classes from the simple and JAX-WS front end into a giant pretzel. So, I could understand your being -1 due to seeing value in thing, or +1 in wanting to make CXF easier to explain, but that giant zero feels like a giant question-mark burning on my lawn. Could you elaborate on your passionate non-attachment, or would that transgress your lack of a position? --benson On Thu, Oct 2, 2008 at 3:43 PM, Glen Mazza <[EMAIL PROTECTED]> wrote: > > I'm passionately neutral. Few things are more deep-felt than my vote of > zero > on this matter. > > Glen > > > Benson Margulies-4 wrote: > > > > Given Dan's message today to a user, I want to toss out the possibility > of > > deprecating the entire Simple front end. > > > > -- > View this message in context: > http://www.nabble.com/Status-of-simple-front-end-tp19785030p19786266.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
Re: Status of simple front end
Well, given that the entire distributed OSGi stuff is based on the Simple frontend + aegis (since OSGi services probably don't have jaxws annotations on them), I would say that it wouldn't be practical to get rid of it. :-) Dan > Benson Margulies-4 wrote: > > Given Dan's message today to a user, I want to toss out the > > possibility of deprecating the entire Simple front end. -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Fwd: CFP open for ApacheCon Europe 2009
-- Forwarded Message -- Subject: CFP open for ApacheCon Europe 2009 Date: Thursday 02 October 2008 From: Noirin Shirley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] PMCs: Please send this on to your users@ lists! If you only have thirty seconds: The Call for Papers for ApacheCon Europe 2009, to be held in Amsterdam, from 23rd to 27th March, is now open! Submit your proposals at http://eu.apachecon.com/c/aceu2009/cfp/ before 24th October. Remember that early bird prices for ApacheCon US 2008, to be held in New Orleans, from 3rd to 7th November, will go up this Friday, at midnight Eastern time! Sponsorship opportunities for ApacheCon US 2008 and ApacheCon EU 2009 are still available. If you or your company are interested in becoming a sponsor, please contact Delia Frees at [EMAIL PROTECTED] for details. *** If you want all the details: ApacheCon Europe 2009 - Leading the Wave of Open Source Amsterdam, The Netherlands 23rd to 27th March, 2009 Call for Papers Opens for ApacheCon Europe 2009 The Apache Software Foundation (ASF) invites submissions to its official conference, ApacheCon Europe 2009. To be held 23rd to 27th March, 2009 at the Mövenpick Hotel Amsterdam City Centre, ApacheCon serves as a forum for showcasing the ASF's latest developments, including its projects, membership, and community. ApacheCon offers unparalleled educational opportunities, with dedicated presentations, hands-on trainings, and sessions that address core technology, development, business/marketing, and licensing issues in Open Source. ApacheCon's wide range of activities are designed to promote the exchange of ideas amongst ASF Members, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes competitively selected presentations, trainings/workshops, and a small number of invited speakers. All sessions undergo a peer review process by the ApacheCon Conference Planning team. The following information provides presentation category descriptions, and information about how to submit your proposal. Conference Themes and Topics APACHECON 2009 - LEADING THE WAVE OF OPEN SOURCE Building on the success of the last two years, we are excited to return to Amsterdam in 2009. We'll be continuing to offer our very popular two-day trainings, including certifications of completion for those who fulfill all the requirements of these trainings. The ASF comprises some of the most active and recognized developers in the Open Source community. By bringing together the pioneers, developers, and users of flagship Open Source technologies, ApacheCon provides an influential platform for dialogue, between the speaker and the audience, between project contributors and the community at large, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions from like-minded delegates across many fields, geographic locations, and areas of development. The breadth and loosely-structured nature of the Apache community lends itself to conference content that is also somewhat loosely-structured. Common themes of interest address groundbreaking technologies and emerging trends, successful practices (from development to deployment), and lessons learned (tips, tools, and tricks). In addition to technical content, ApacheCon invites Business Track submissions that address Open Source business, marketing, and legal/licensing issues. Topics appropriate for submission to this conference are manifold, and may include but are not restricted to: - Apache HTTP server topics such as installation, configuration, and migration - ASF-wide projects such as Lucene, SpamAssassin, Jackrabbit, and Maven - Scripting languages and dynamic content such as Java, Perl, Python, Ruby, XSL, and PHP - Security and e-commerce - Performance tuning, load balancing and high availability - New technologies and broader initiatives such as Web Services and Web 2.0 - ASF-Incubated projects such as Sling, UIMA, and Shindig Submission Guidelines Submissions must include - Title - Speaker name, with affiliation and email address - Speaker bio (100 words or less) - Short description (50 words or less) - Full description including abstract and objectives (200 words or less) - Expertise level (beginner to advanced) - Format and duration (trainings vs. general presentation; half-, full- or two-day workshop, etc.) - Intended audience and maximum number of participants (trainings only) - Background knowledge expected of the participants (trainings only) Types of Presentations - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Invited Keynotes/Panels/Speakers - Corporate Showcases & Demonstrations BoF sessions and Fast Feather Track talks will be selected separately Pre Conference Trainings/Workshops Held on the first and second day of the conference – 2008-03-23 and 2008-03-24, Trainings require a reg
Re: Status of simple front end
That's what I call an argument. OK, so much for that. Should we try to make Simple quietly respect @WebParam and friends? On Thu, Oct 2, 2008 at 4:46 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Well, given that the entire distributed OSGi stuff is based on the Simple > frontend + aegis (since OSGi services probably don't have jaxws > annotations on them), I would say that it wouldn't be practical to get > rid of it. :-) > > Dan > > > > Benson Margulies-4 wrote: > > > Given Dan's message today to a user, I want to toss out the > > > possibility of deprecating the entire Simple front end. > > > > -- > J. Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog >
Re: Status of simple front end
Basically, fence-sitting. I can definitely see how its removal would be one less moving part to maintain, and it would also nicely simplify CXF's documentation, and provide less confusion for users. CXF has grown a lot--now REST, JMS, WS-Security--and some trimming of its branches (i.e., becoming leaner and meaner) by removing the simple front end could have been helpful for the project. But I needed more input from other committers to be dislodged from my passionate 0 vote. Dan provided it here. Glen Benson Margulies-4 wrote: > > Glen, > > I am somewhat puzzled by your position. You put a lot of work into > explaining CXF to people. The existence of the simple front end is one > more > thing to explain. I just fielded a JIRA from someone who had managed to > combine classes from the simple and JAX-WS front end into a giant pretzel. > So, I could understand your being -1 due to seeing value in thing, or +1 > in > wanting to make CXF easier to explain, but that giant zero feels like a > giant question-mark burning on my lawn. > > Could you elaborate on your passionate non-attachment, or would that > transgress your lack of a position? > > --benson > -- View this message in context: http://www.nabble.com/Status-of-simple-front-end-tp19785030p19788442.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Status of simple front end
OK, then, you guys might rise to the bait I offered on the subject of renaming the classes to actually have 'Simple' in their names :p) On Thu, Oct 2, 2008 at 6:04 PM, Glen Mazza <[EMAIL PROTECTED]> wrote: > > Basically, fence-sitting. I can definitely see how its removal would be > one > less moving part to maintain, and it would also nicely simplify CXF's > documentation, and provide less confusion for users. CXF has grown a > lot--now REST, JMS, WS-Security--and some trimming of its branches (i.e., > becoming leaner and meaner) by removing the simple front end could have > been > helpful for the project. But I needed more input from other committers to > be dislodged from my passionate 0 vote. Dan provided it here. > > Glen > > > Benson Margulies-4 wrote: > > > > Glen, > > > > I am somewhat puzzled by your position. You put a lot of work into > > explaining CXF to people. The existence of the simple front end is one > > more > > thing to explain. I just fielded a JIRA from someone who had managed to > > combine classes from the simple and JAX-WS front end into a giant > pretzel. > > So, I could understand your being -1 due to seeing value in thing, or +1 > > in > > wanting to make CXF easier to explain, but that giant zero feels like a > > giant question-mark burning on my lawn. > > > > Could you elaborate on your passionate non-attachment, or would that > > transgress your lack of a position? > > > > --benson > > > > -- > View this message in context: > http://www.nabble.com/Status-of-simple-front-end-tp19785030p19788442.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
Re: Release manager for 2.1.3 and/or 2.0.9.....
Hi Dan, I'd like to take charge of this CXF release. Since you and me met a year before, I will send you my key for signing :) Cheers, Willem On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases. > It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2. We have > 33 issues resolved for 2.0.9, and 38 for 2.1.3. Thus, we probably > should consider doing some releases shortly. > > HOWEVER, my hard drive crashed this week and part of recovering from > that, I kind of realized that someone else really should try doing a > release to make sure the knowledge is spread out a bit and isn't all > bottled up in my head.Thus, I'd like to ask for volunteers for doing > the releases. If no one jumps up, I'll be happy to do it, but it would > definitely be good to get someone else involved. > > Requirements: > 1) The release process is MUCH easier and more reliable on a Linux or OSX > box. Things like gpg and ssh/scp "just work". If someone want to try > Windows, I'm not sure how much I can help. > > 2) gpg installed and a gpg key generated and available in the public key > servers. Ideally, it would be signed by other apache folks, but that's > not a requirment. Anyone near Boston, we could meet for lunch and sign > keys if you want. > > 3) Time - before building the release, you need a few hours to review > release notes, notice/license files, rat reports, etc Post > release, there is syncing to the maven repo, updating confluence, some > JIRA admin things, etc Basically, a few hours ahead of the build, > an hour to build, three days for the vote, and a few hours afterword. > > Anyway, if anyone is interested, speak up. I'd be happy to look over > your virtual shoulder while you do the stuff to make sure it's all done > right. Not a problem. > > Thanks! > > -- > J. Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog >
