Re: [VOTE] The retirement of Apache jUDDI (moving to the Apache Attic)

[Kurt Stam]

+1 from me—KurtOn Dec 22, 2022, at 01:00, Alex O'Ree  wrote:Resending...2 votes is not enough to pass, otherwise the board may have to take action directlyOn Thu, Dec 15, 2022 at 12:52 PM Steve Viens  wrote:+1 from me as well.SteveOn Wed, Dec 14, 2022 at 7:28 PM Alex O'Ree  wrote:After some discussion over the past month or so, there seems to be enough of a consensus to hold a vote on retiring Apache jUDDI. I've pretty much been the only maintainer for a while now and unfortunately have a number of outstanding issues that I can't solve without assistance from the community.Unfortunately, most, if not all, of the committers and other community members have moved on to other projects. Usage of the UDDI specification and Apache jUDDI has never really been that high in general. Recently over the fast few years, JIRA issue reporting, mailing list traffic and all known out of band traffic have been near zero. Download statistics are pretty minimal as well and if anyone is using our libraries, there's little recent evidence to support that via mvnreponsitory.com's cross reference capabilities.The process for moving a project to the Attic is outlined here: https://attic.apache.org/process.htmlOn Nov 11th, an email was dispatched to both the user and dev lists about this with no replies. It's time for the formal vote.+1 from me
-- Steve Vienssvi...@gmail.com603-828-2397

Re: Moving jUDDI to the attic

[Kurt Stam]

Hi Alex,

Totally understand your frustration. I think it maybe time. I don’t see a lot 
of active users on the project. Are there stats on downloads? I think the 
current maintainers are not unwilling but have no active UDDI involvement going 
on which makes it hard to find time for it. 

Curious to hear what other people think

—Kurt

> On Nov 9, 2022, at 21:38, Alex O'Ree  wrote:
> 
> 
> Anyone alive? Or should we start discussing moving this project to the attic? 
> 
> I'm getting tired of maintaining this project by myself. I understand 
> everyone is busy with other stuff. I am too, but we do have a certain level 
> of responsibility for supporting this project.
> 
> Is it time to call the vote on retiring jUDDI?

Re: Juddi developers - hibernate issues

[Kurt Stam]

I will look at it Alex - this coming week I should have time 

> On Jul 16, 2022, at 11:06, Alex O'Ree  wrote:
> 
> 
> Ehm,...
> 
>> On Thu, Jul 7, 2022 at 8:30 PM Alex O'Ree  wrote:
>> Anyone alive? Or should we start discussing moving this project to the 
>> attic? 
>> 
>>> On Sat, Jul 2, 2022 at 11:08 AM Alex O'Ree  wrote:
>>> Greetings everyone
>>> 
>>> I have been working towards getting CI services back up and running using 
>>> github actions (the older buildbot configuration hasn't worked a while). 
>>> While i've made progress in getting it working, i've noticed that the 
>>> hibernate specific profile has been broken for quite some time. I'm not 
>>> entirely sure the last time it did work. I've tried a variety of different 
>>> versions that we have used in the past as well as the latest and nearly 
>>> every version inbetween, all with similar issues. See 
>>> https://issues.apache.org/jira/browse/JUDDI-1024 for details.
>>> 
>>> At this point, I'm at a loss on what to do next.
>>> COA1) Someone smarter than me can attempt to fix our hibernate support
>>> COA2) Remove hibernate support entirely but i didn't want to make such a 
>>> large change without consulting the community. 
>>> COA3) ???
>>> 
>>> Looking for feedback, advice or opinions on the matter
>>> 
>>> 
>>> 

[jira] [Closed] (SCOUT-138) Access to Scout Production

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/SCOUT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam closed SCOUT-138.
---
Resolution: Invalid

That's not us..

> Access to Scout Production
> --
>
> Key: SCOUT-138
> URL: https://issues.apache.org/jira/browse/SCOUT-138
> Project: Scout
>  Issue Type: Bug
>Reporter: Amanda
>Assignee: Kurt Stam
>Priority: Major
>
> Hello, may I be please be setup with a production account for Connect? Thank 
> you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SCOUT-138) Access to Scout Production

[Kurt Stam (Jira)]

[ 
https://issues.apache.org/jira/browse/SCOUT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388163#comment-17388163
 ] 

Kurt Stam commented on SCOUT-138:
-

Hi Amanda, I Scout is an API implementation sitting on top of UDDI and ebXML. 
We don't do any hosting to those systems. What is it you are looking for?

> Access to Scout Production
> --
>
> Key: SCOUT-138
> URL: https://issues.apache.org/jira/browse/SCOUT-138
> Project: Scout
>  Issue Type: Bug
>Reporter: Amanda
>Assignee: Kurt Stam
>Priority: Major
>
> Hello, may I be please be setup with a production account for Connect? Thank 
> you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] jUDDI v3.3.10

[Kurt Stam]

+1

> On Jun 22, 2021, at 22:27, Alex O'Ree  wrote:
> 
> 
> Dear jUDDI enthusiasts,
> 
> The new release is here! This release resolves 1 JIRA for an unspecified 
> security issue.
> 
> The release distribution is temporarily available here
> https://www.dropbox.com/sh/t1m6md4sjphsoqc/AACOiHR6EV7ohKOtIMe83d3Aa?dl=0
> 
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1020
> 
> and we have a tag at:
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.1
> 
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
> 
> +1 for me
> 
> Bug
> 
> [JUDDI-1018] - TBD

[jira] [Updated] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam updated JUDDI-1017:
-
External issue URL:   (was: https://www.mc88bet.poker/)

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam closed JUDDI-1017.

Resolution: Won't Do

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam updated JUDDI-1017:
-
Description: (was: Mc88poker merupakan salah satu tempat [*daftar idn 
poker88*|https://www.mc88bet.poker/] terbaik yang ada di asia.
Karena selalu mengutamakan keamanan dan kenyamanan dari setiap anggotanya.
Mc88poker juga selalu memberikan berbagai bonus menarik baik untuk para member 
atau pun calon member.
Jadi langsung saja bergabung di mc88poker tempat daftar idn poker88 terbaik.)

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam reopened JUDDI-1017:
--

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>
> Mc88poker merupakan salah satu tempat [*daftar idn 
> poker88*|https://www.mc88bet.poker/] terbaik yang ada di asia.
> Karena selalu mengutamakan keamanan dan kenyamanan dari setiap anggotanya.
> Mc88poker juga selalu memberikan berbagai bonus menarik baik untuk para 
> member atau pun calon member.
> Jadi langsung saja bergabung di mc88poker tempat daftar idn poker88 terbaik.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

 [ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam closed JUDDI-1017.

Resolution: Won't Do

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>
> Mc88poker merupakan salah satu tempat [*daftar idn 
> poker88*|https://www.mc88bet.poker/] terbaik yang ada di asia.
> Karena selalu mengutamakan keamanan dan kenyamanan dari setiap anggotanya.
> Mc88poker juga selalu memberikan berbagai bonus menarik baik untuk para 
> member atau pun calon member.
> Jadi langsung saja bergabung di mc88poker tempat daftar idn poker88 terbaik.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JUDDI-1017) best feature in website

[Kurt Stam (Jira)]

[ 
https://issues.apache.org/jira/browse/JUDDI-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17295934#comment-17295934
 ] 

Kurt Stam commented on JUDDI-1017:
--

situsidnpokermc88 needs to be banned - this is spam

> best feature in website
> ---
>
> Key: JUDDI-1017
> URL: https://issues.apache.org/jira/browse/JUDDI-1017
> Project: jUDDI
>  Issue Type: New Feature
>Reporter: situsidnpokermc88
>Priority: Major
>
> Mc88poker merupakan salah satu tempat [*daftar idn 
> poker88*|https://www.mc88bet.poker/] terbaik yang ada di asia.
> Karena selalu mengutamakan keamanan dan kenyamanan dari setiap anggotanya.
> Mc88poker juga selalu memberikan berbagai bonus menarik baik untuk para 
> member atau pun calon member.
> Jadi langsung saja bergabung di mc88poker tempat daftar idn poker88 terbaik.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] jUDDI v3.3.9

[Kurt Stam]

+1 from me! —Kurt

On Aug 15, 2020, at 15:48, Steve Viens  wrote:


+1 from me!

Steve Viens
svi...@gmail.com
603-828-2397


On Sat, Aug 15, 2020 at 9:39 AM Alex O'Ree  wrote:

> Dear jUDDI enthusiasts,
>
> The new release is here! This release resolves 11 JIRAs, 3 enhancements
> and the rest bugs. I did update the release notes in the distro, however I
> had incorrectly labeled some of the JIRA as being fixed in the previous
> version so it's missing a few issues. It's corrected in JIRA now
>
> The release distribution is temporarily available here
> https://www.dropbox.com/sh/k2ojoye8y2916bf/AACRJoqqI5X4zlTKBlhASjCma?dl=0
>
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1019
>
> and we have a tag at:
>
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.9
>
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing
> that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
>
> +1 for me
>
> Bug
>
>- [JUDDI-1004 ] -
>JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table
>j3_category_bag
>- [JUDDI-1006 ] -
>Saving an Access Point Type
>- [JUDDI-1008 ] -
>find_business returns an error when querying a tModel when using the v2
>Inquire API
>- [JUDDI-1009 ] -
>Browse Businesses using juddiv2 page navigation issue
>- [JUDDI-1010 ] -
>save_business does not properly save the accessPoint URLType when using the
>v2 Publish API
>- [JUDDI-1011 ] - MS
>SQL Server table - length of field too large
>- [JUDDI-1013 ] -
>GUI adding records
>- [JUDDI-1015 ] -
>Oracle database start up issue due to max string length
>
> Improvement
>
>- [JUDDI-1012 ] - MS
>SQL Server Sequence table change
>- [JUDDI-1014 ] -
>Binding Editor – tModel Instance Information
>- [JUDDI-1016 ] -
>Add DDL generators for all available hibernate supported dialetcs
>
>

Re: [VOTE] jUDDI v3.3.8

[Kurt Stam]

+1

> On Mar 15, 2020, at 08:47, Anil Saldanha  wrote:
> 
> +1
> 
>>> On Mar 12, 2020, at 1:26 PM, Kurt Stam  wrote:
>>> 
>> 
>> I promise to check out tonight! —Kurt
>> 
>>>> On Mar 12, 2020, at 06:27, Alex O'Ree  wrote:
>>>> 
>>> 
>>> 5 days and no responses...
>>> 
>>>> On Sat, Mar 7, 2020, 7:36 PM Alex O'Ree  wrote:
>>>> Dear jUDDI enthusiasts,
>>>> 
>>>> The new release is here! This release resolves 4 JIRAs, 2 bugs and 2 minor 
>>>> enhancements. I did miss updating the release notes within the distro but
>>>> 
>>>> The release distribution is temporarily available here
>>>> https://www.dropbox.com/sh/mknyo1s4g7er3wl/AAAGJf9LuCDRt1et4tqlKa8ua?dl=0
>>>> 
>>>> The release artifacts are staged in nexus:
>>>> https://repository.apache.org/content/repositories/orgapachejuddi-1018
>>>> 
>>>> and we have a tag at:
>>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.8
>>>> 
>>>> Please give it a spin and cast your vote. This vote will be open for
>>>> the next 72 hours per the release policy, which is:
>>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>>> votes are received with no -1 vote being cast, or
>>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>>> that
>>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>>> a majority of +1 votes from the cast votes.
>>>> 
>>>> +1 for me
>>>> 
>>>> 
>>>> Bug
>>>> 
>>>> [JUDDI-937] - PolicyRoundRobin not working without service cache
>>>> [JUDDI-1003] - spring-web jar supplied with latest JUDDI distribution has 
>>>> security vulnerability
>>>> Improvement
>>>> 
>>>> [JUDDI-993] - InVm transport for embedded juddi needs to handle 
>>>> authentication and a sample for usage
>>>> [JUDDI-1002] - tModelInstanceInfo value does not check for maximum length

Re: [VOTE] jUDDI v3.3.8

[Kurt Stam]

I promise to check out tonight! —Kurt

> On Mar 12, 2020, at 06:27, Alex O'Ree  wrote:
> 
> 
> 5 days and no responses...
> 
>> On Sat, Mar 7, 2020, 7:36 PM Alex O'Ree  wrote:
>> Dear jUDDI enthusiasts,
>> 
>> The new release is here! This release resolves 4 JIRAs, 2 bugs and 2 minor 
>> enhancements. I did miss updating the release notes within the distro but
>> 
>> The release distribution is temporarily available here
>> https://www.dropbox.com/sh/mknyo1s4g7er3wl/AAAGJf9LuCDRt1et4tqlKa8ua?dl=0
>> 
>> The release artifacts are staged in nexus:
>> https://repository.apache.org/content/repositories/orgapachejuddi-1018
>> 
>> and we have a tag at:
>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.8
>> 
>> Please give it a spin and cast your vote. This vote will be open for
>> the next 72 hours per the release policy, which is:
>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>> votes are received with no -1 vote being cast, or
>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>>  - after 72h provided at least 3 +1 votes have been cast and there is
>> a majority of +1 votes from the cast votes.
>> 
>> +1 for me
>> 
>> 
>> Bug
>> 
>> [JUDDI-937] - PolicyRoundRobin not working without service cache
>> [JUDDI-1003] - spring-web jar supplied with latest JUDDI distribution has 
>> security vulnerability
>> Improvement
>> 
>> [JUDDI-993] - InVm transport for embedded juddi needs to handle 
>> authentication and a sample for usage
>> [JUDDI-1002] - tModelInstanceInfo value does not check for maximum length

Re: [VOTE] jUDDI v3.3.7

[Kurt Stam]

+1 from me! —Kurt

> On Jan 11, 2020, at 11:53, Anil Saldanha  wrote:
> 
> +1 from me
> 
>>> On Jan 11, 2020, at 7:29 AM, Alex O'Ree  wrote:
>>> 
>> 
>> Any other votes on this? there are at least 5 voting members on this board.
>> 
>>> On Sat, Dec 14, 2019 at 9:56 PM Alex O'Ree  wrote:
>>> Dear jUDDI enthusiasts,
>>> 
>>> The new release is here! This release resolves 6 JIRAs, 4 bugs, 1 build 
>>> related issue, and one maintenance issue.
>>> 
>>> The release distribution is temporarily available here (without hashes)
>>> https://www.dropbox.com/sh/28qfjhx0h38h3dg/AADVdOIkStgu88y2ggXU-_F5a?dl=0
>>> 
>>> The release artifacts are staged in nexus:
>>> https://repository.apache.org/content/repositories/orgapachejuddi-1017
>>> 
>>> and we have a tag at:
>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.7
>>> 
>>> Please give it a spin and cast your vote. This vote will be open for
>>> the next 72 hours per the release policy, which is:
>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>> votes are received with no -1 vote being cast, or
>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>> that
>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>> a majority of +1 votes from the cast votes.
>>> 
>>> +1 for me
>>> 
>>> Bug
>>> 
>>> [JUDDI-991] - JUDDI Uses EOL Version of Apache CXF
>>> [JUDDI-996] - Admin gui, get all client subscriptions throws a classcast 
>>> error
>>> [JUDDI-997] - Admin gui has strange behavior and no feedback if the login 
>>> fails
>>> [JUDDI-999] - Issue with SQL Server Database with JUDDI 3.3.6 : The size 
>>> (8192) given to the column 'instance_parms' exceeds the maximum allowed for 
>>> any data type (8000)
>>> Improvement
>>> 
>>> [JUDDI-995] - Add automated generation of sha512 hashes during the build
>>> [JUDDI-1000] - Update embedded tomcat to the latest version available

Re: [VOTE] jUDDI v3.3.7

[Kurt Stam]

Java 8. I don’t see errors in the logs. 

> On Dec 18, 2019, at 14:35, Alex O'Ree  wrote:
> 
> 
> correction java 10
> 
>> On Wed, Dec 18, 2019 at 2:16 PM Alex O'Ree  wrote:
>> Kurt, it started up here ok, what version of java?
>> 
>>> On Wed, Dec 18, 2019 at 1:19 PM Kurt Stam  wrote:
>>> In the tomcat bundle the server backend /juddiv3 does not seem to start
>>> 
>>>>> On Dec 18, 2019, at 07:37, Kurt Stam  wrote:
>>>>> 
>>>> 
>>>> Will check it out today!
>>>> 
>>>>>> On Dec 18, 2019, at 07:29, Alex O'Ree  wrote:
>>>>>> 
>>>>> 
>>>>> Pingno responses in 4 days.
>>>>> 
>>>>> Also when further researching [JUDDI-999], it looks like we are not 
>>>>> performing length checks on tmodel instance information tags. I don't 
>>>>> think it's a major issue and it can wait until the next one.
>>>>> 
>>>>> 
>>>>>> On Sat, Dec 14, 2019 at 9:56 PM Alex O'Ree  wrote:
>>>>>> Dear jUDDI enthusiasts,
>>>>>> 
>>>>>> The new release is here! This release resolves 6 JIRAs, 4 bugs, 1 build 
>>>>>> related issue, and one maintenance issue.
>>>>>> 
>>>>>> The release distribution is temporarily available here (without hashes)
>>>>>> https://www.dropbox.com/sh/28qfjhx0h38h3dg/AADVdOIkStgu88y2ggXU-_F5a?dl=0
>>>>>> 
>>>>>> The release artifacts are staged in nexus:
>>>>>> https://repository.apache.org/content/repositories/orgapachejuddi-1017
>>>>>> 
>>>>>> and we have a tag at:
>>>>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.7
>>>>>> 
>>>>>> Please give it a spin and cast your vote. This vote will be open for
>>>>>> the next 72 hours per the release policy, which is:
>>>>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>>>>> votes are received with no -1 vote being cast, or
>>>>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>>>>> that
>>>>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>>>>> a majority of +1 votes from the cast votes.
>>>>>> 
>>>>>> +1 for me
>>>>>> 
>>>>>> Bug
>>>>>> 
>>>>>> [JUDDI-991] - JUDDI Uses EOL Version of Apache CXF
>>>>>> [JUDDI-996] - Admin gui, get all client subscriptions throws a classcast 
>>>>>> error
>>>>>> [JUDDI-997] - Admin gui has strange behavior and no feedback if the 
>>>>>> login fails
>>>>>> [JUDDI-999] - Issue with SQL Server Database with JUDDI 3.3.6 : The size 
>>>>>> (8192) given to the column 'instance_parms' exceeds the maximum allowed 
>>>>>> for any data type (8000)
>>>>>> Improvement
>>>>>> 
>>>>>> [JUDDI-995] - Add automated generation of sha512 hashes during the build
>>>>>> [JUDDI-1000] - Update embedded tomcat to the latest version available

Re: [VOTE] jUDDI v3.3.7

[Kurt Stam]

In the tomcat bundle the server backend /juddiv3 does not seem to start

> On Dec 18, 2019, at 07:37, Kurt Stam  wrote:
> 
> 
> Will check it out today!
> 
>>> On Dec 18, 2019, at 07:29, Alex O'Ree  wrote:
>>> 
>> 
>> Pingno responses in 4 days.
>> 
>> Also when further researching [JUDDI-999], it looks like we are not 
>> performing length checks on tmodel instance information tags. I don't think 
>> it's a major issue and it can wait until the next one.
>> 
>> 
>>> On Sat, Dec 14, 2019 at 9:56 PM Alex O'Ree  wrote:
>>> Dear jUDDI enthusiasts,
>>> 
>>> The new release is here! This release resolves 6 JIRAs, 4 bugs, 1 build 
>>> related issue, and one maintenance issue.
>>> 
>>> The release distribution is temporarily available here (without hashes)
>>> https://www.dropbox.com/sh/28qfjhx0h38h3dg/AADVdOIkStgu88y2ggXU-_F5a?dl=0
>>> 
>>> The release artifacts are staged in nexus:
>>> https://repository.apache.org/content/repositories/orgapachejuddi-1017
>>> 
>>> and we have a tag at:
>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.7
>>> 
>>> Please give it a spin and cast your vote. This vote will be open for
>>> the next 72 hours per the release policy, which is:
>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>> votes are received with no -1 vote being cast, or
>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>> that
>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>> a majority of +1 votes from the cast votes.
>>> 
>>> +1 for me
>>> 
>>> Bug
>>> 
>>> [JUDDI-991] - JUDDI Uses EOL Version of Apache CXF
>>> [JUDDI-996] - Admin gui, get all client subscriptions throws a classcast 
>>> error
>>> [JUDDI-997] - Admin gui has strange behavior and no feedback if the login 
>>> fails
>>> [JUDDI-999] - Issue with SQL Server Database with JUDDI 3.3.6 : The size 
>>> (8192) given to the column 'instance_parms' exceeds the maximum allowed for 
>>> any data type (8000)
>>> Improvement
>>> 
>>> [JUDDI-995] - Add automated generation of sha512 hashes during the build
>>> [JUDDI-1000] - Update embedded tomcat to the latest version available

Re: [VOTE] jUDDI v3.3.7

[Kurt Stam]

Will check it out today!

On Dec 18, 2019, at 07:29, Alex O'Ree  wrote:


Pingno responses in 4 days.

Also when further researching [JUDDI-999], it looks like we are not
performing length checks on tmodel instance information tags. I don't think
it's a major issue and it can wait until the next one.


On Sat, Dec 14, 2019 at 9:56 PM Alex O'Ree  wrote:

> Dear jUDDI enthusiasts,
>
> The new release is here! This release resolves 6 JIRAs, 4 bugs, 1 build
> related issue, and one maintenance issue.
>
> The release distribution is temporarily available here (without hashes)
> https://www.dropbox.com/sh/28qfjhx0h38h3dg/AADVdOIkStgu88y2ggXU-_F5a?dl=0
>
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1017
>
> and we have a tag at:
>
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.7
>
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing
> that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
>
> +1 for me
>
> Bug
>
>- [JUDDI-991 ] - JUDDI
>Uses EOL Version of Apache CXF
>- [JUDDI-996 ] - Admin
>gui, get all client subscriptions throws a classcast error
>- [JUDDI-997 ] - Admin
>gui has strange behavior and no feedback if the login fails
>- [JUDDI-999 ] - Issue
>with SQL Server Database with JUDDI 3.3.6 : The size (8192) given to the
>column 'instance_parms' exceeds the maximum allowed for any data type 
> (8000)
>
> Improvement
>
>- [JUDDI-995 ] - Add
>automated generation of sha512 hashes during the build
>- [JUDDI-1000 ] -
>Update embedded tomcat to the latest version available
>
>

Re: Let's Encrypt certificate expiration notice for domain "demo.juddi.apache.org"

[Kurt Stam]

Ok man - my life has been a bit crazy but I can help tomorrow if still
needed

On Oct 19, 2019, at 16:30, Alex O'Ree  wrote:


no problem...i'll get it. on it now... there may be some temporary ssl
outages while i trey to remember how to do this

On Sat, Oct 5, 2019 at 8:11 PM Alex O'Ree  wrote:

> any volunteers?
>
> -- Forwarded message -
> From: Let's Encrypt Expiry Bot 
> Date: Sat, Oct 5, 2019 at 6:39 PM
> Subject: Let's Encrypt certificate expiration notice for domain "
> demo.juddi.apache.org"
> To:
>
>
> Hello,
>
> Your certificate (or certificates) for the names listed below will expire
> in 19 days (on 25 Oct 19 22:22 +). Please make sure to renew your
> certificate before then, or visitors to your website will encounter errors.
>
> We recommend renewing certificates automatically when they have a third of
> their
> total lifetime left. For Let's Encrypt's current 90-day certificates, that
> means
> renewing 30 days before expiration. See
> https://letsencrypt.org/docs/integration-guide/ for details.
>
> demo.juddi.apache.org
>
> For any questions or support, please visit
> https://community.letsencrypt.org/. Unfortunately, we can't provide
> support by email.
>
> For details about when we send these emails, please visit
> https://letsencrypt.org/docs/expiration-emails/. In particular, note that
> this reminder email is still sent if you've obtained a slightly different
> certificate by adding or removing names. If you've replaced this
> certificate with a newer one that covers more or fewer names than the list
> above, you may be able to ignore this message.
>
>
>
> Regards,
> The Let's Encrypt Team
>

Re: Updating the demo site

[Kurt Stam]

File creation in /tmp/juddi-db works like a charm, not so much in 
/var/lib/tomcat9/juddi-db

https://issues.apache.org/jira/browse/INFRA-19146 
<https://issues.apache.org/jira/browse/INFRA-19146>



> On Sep 24, 2019, at 6:20 PM, Alex O'Ree  wrote:
> 
> I don't care either way, but persistent storage would be nice.
> 
> On Tue, Sep 24, 2019, 5:31 AM Kurt Stam  <mailto:kurt.s...@gmail.com>> wrote:
> Thanks I see it now!
> 
> So before, the cloud instance was used PostgreSQL. Do we really want to use 
> Derby? I will look into the permission issue as soon as I have a second to 
> follow the instructions to get sudo.
> 
> —Kurt
> 
>> On Sep 23, 2019, at 11:53 PM, Alex O'Ree > <mailto:alexo...@apache.org>> wrote:
>> 
>> Juddi is already installed and running on the vm from the head of the git 
>> repo with tomcat 9 I believe. The problem is derby won't fire up using the 
>> file system for storage. Only the in memory db would work. I think I the 
>> problem is file system permissions but I am not sure how to fix it.
>> 
>> 
>> On Mon, Sep 23, 2019, 11:08 AM Kurt Stam > <mailto:ks...@redhat.com>> wrote:
>> OK I’m in after https://issues.apache.org/jira/browse/INFRA-19130 
>> <https://issues.apache.org/jira/browse/INFRA-19130>
>> 
>> 
>> So Alex should we use a PostgreSQL DB? WDYT?
>> 
>> Also the easiest is to get started using the preconfigured juddi-tomcat from 
>> juddi-distro-3.3.6.zip 
>> <http://apache.cs.uu.nl/juddi/juddi/3.3.6/juddi-distro-3.3.6.zip>, which 
>> actually has some issues on JDK8
>> 
>> NOTE: Picked up JDK_JAVA_OPTIONS:  
>> --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io 
>> <http://java.io/>=ALL-UNNAMED 
>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>> OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was 
>> removed in 8.0
>> OpenJDK 64-Bit Server VM warning: Ignoring option PermSize; support was 
>> removed in 8.0
>> -Djava.endorsed.dirs=/home/kstam/juddi-distro-3.3.6/juddi-tomcat-3.3.6/endorsed
>>  is not supported. Endorsed standards and standalone APIs
>> in modular form will be supported via the concept of upgradeable modules.
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> So we either use a older JDK, or we need to release jUDDI with a newer 
>> tomcat version.
>> 
>> How do you guys want to proceed?
>> 
>> —Kurt
>> 
>>> On Sep 22, 2019, at 2:26 PM, Kurt Stam >> <mailto:ks...@redhat.com>> wrote:
>>> 
>>> Don’t Bernie me: https://www.youtube.com/watch?v=VGTaE1cLyJA 
>>> <https://www.youtube.com/watch?v=VGTaE1cLyJA>
>>> 
>>>> On Sep 21, 2019, at 11:41 PM, Steve Viens >>> <mailto:svi...@gmail.com>> wrote:
>>>> 
>>>> Not Guilty! ... but good grief - I am totally guilty of negligence.  I 
>>>> completely forgot about this.  My apologies.
>>>> 
>>>> Steve
>>>> 
>>>> 
>>>> 
>>>> On Sat, Sep 21, 2019 at 4:23 PM Kurt Stam >>> <mailto:kurt.s...@gmail.com>> wrote:
>>>> Steve did it!
>>>> 
>>>>> On Sep 21, 2019, at 22:20, Alex O'Ree >>>> <mailto:spyhunte...@gmail.com>> wrote:
>>>>> 
>>>>> 
>>>>> did anyone delete the root business? hmmm
>>>>> 
>>>>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens >>>> <mailto:svi...@gmail.com>> wrote:
>>>>> Awesome Alex.  I’ve been buried for past two weeks and just catching up 
>>>>> with personal email and saw yours.  I’ll take a look as soon as I can.
>>>>> 
>>>>> Steve 
>>>>> 
>>>>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree >>>> <mailto:alexo...@apache.org>> wrote:
>>>>> good news, i got the demo set up and running
>>>>> 
>>>>> https://demo.juddi.apache.org/ <https://demo.juddi.apache.org/>
>>>>> some important paths
>>>>> /var/log/tomcat9
>>>>> /var/lib/tomcat9/webapps
>>>>> /etc/tomcat9
>>>>> 
>>>>> the original tomcat root app was moved to /opt in case we need it in the 
>>>>> future.
>>>>> ssl cert is via lets encrypt, good until oct 25th
>>>>> 
>>>>> the hard part was getting derby to fire up. 

Re: Updating the demo site

[Kurt Stam]

Thanks I see it now!

So before, the cloud instance was used PostgreSQL. Do we really want to use 
Derby? I will look into the permission issue as soon as I have a second to 
follow the instructions to get sudo.

—Kurt

> On Sep 23, 2019, at 11:53 PM, Alex O'Ree  wrote:
> 
> Juddi is already installed and running on the vm from the head of the git 
> repo with tomcat 9 I believe. The problem is derby won't fire up using the 
> file system for storage. Only the in memory db would work. I think I the 
> problem is file system permissions but I am not sure how to fix it.
> 
> 
> On Mon, Sep 23, 2019, 11:08 AM Kurt Stam  <mailto:ks...@redhat.com>> wrote:
> OK I’m in after https://issues.apache.org/jira/browse/INFRA-19130 
> <https://issues.apache.org/jira/browse/INFRA-19130>
> 
> 
> So Alex should we use a PostgreSQL DB? WDYT?
> 
> Also the easiest is to get started using the preconfigured juddi-tomcat from 
> juddi-distro-3.3.6.zip 
> <http://apache.cs.uu.nl/juddi/juddi/3.3.6/juddi-distro-3.3.6.zip>, which 
> actually has some issues on JDK8
> 
> NOTE: Picked up JDK_JAVA_OPTIONS:  
> --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io 
> <http://java.io/>=ALL-UNNAMED 
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was 
> removed in 8.0
> OpenJDK 64-Bit Server VM warning: Ignoring option PermSize; support was 
> removed in 8.0
> -Djava.endorsed.dirs=/home/kstam/juddi-distro-3.3.6/juddi-tomcat-3.3.6/endorsed
>  is not supported. Endorsed standards and standalone APIs
> in modular form will be supported via the concept of upgradeable modules.
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> So we either use a older JDK, or we need to release jUDDI with a newer tomcat 
> version.
> 
> How do you guys want to proceed?
> 
> —Kurt
> 
>> On Sep 22, 2019, at 2:26 PM, Kurt Stam > <mailto:ks...@redhat.com>> wrote:
>> 
>> Don’t Bernie me: https://www.youtube.com/watch?v=VGTaE1cLyJA 
>> <https://www.youtube.com/watch?v=VGTaE1cLyJA>
>> 
>>> On Sep 21, 2019, at 11:41 PM, Steve Viens >> <mailto:svi...@gmail.com>> wrote:
>>> 
>>> Not Guilty! ... but good grief - I am totally guilty of negligence.  I 
>>> completely forgot about this.  My apologies.
>>> 
>>> Steve
>>> 
>>> 
>>> 
>>> On Sat, Sep 21, 2019 at 4:23 PM Kurt Stam >> <mailto:kurt.s...@gmail.com>> wrote:
>>> Steve did it!
>>> 
>>>> On Sep 21, 2019, at 22:20, Alex O'Ree >>> <mailto:spyhunte...@gmail.com>> wrote:
>>>> 
>>>> 
>>>> did anyone delete the root business? hmmm
>>>> 
>>>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens >>> <mailto:svi...@gmail.com>> wrote:
>>>> Awesome Alex.  I’ve been buried for past two weeks and just catching up 
>>>> with personal email and saw yours.  I’ll take a look as soon as I can.
>>>> 
>>>> Steve 
>>>> 
>>>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree >>> <mailto:alexo...@apache.org>> wrote:
>>>> good news, i got the demo set up and running
>>>> 
>>>> https://demo.juddi.apache.org/ <https://demo.juddi.apache.org/>
>>>> some important paths
>>>> /var/log/tomcat9
>>>> /var/lib/tomcat9/webapps
>>>> /etc/tomcat9
>>>> 
>>>> the original tomcat root app was moved to /opt in case we need it in the 
>>>> future.
>>>> ssl cert is via lets encrypt, good until oct 25th
>>>> 
>>>> the hard part was getting derby to fire up. it ended up at 
>>>> /etc/tomcat9/Catalina/...
>>>> all other locations had file permissions issues (or maybe a security 
>>>> manager?)
>>>> 
>>>> finally the site also runs on port 80 if needed, but tls should be used 
>>>> when possible.
>>>> 
>>>> On Sat, Jul 27, 2019 at 5:23 PM Alex O'Ree >>> <mailto:alexo...@apache.org>> wrote:
>>>> Steve, Kurt
>>>> 
>>>> Please confirm that you can sign into (via ssh) demo.juddi.apache.org 
>>>> <http://demo.juddi.apache.org/>
>>>> use your asf credentials. You'll also want to test sudoing. ASF infra uses 
>>>> something all opie for open time passwords for sudo.
>>>> Details here: 
>>>> https://issues.apache.org

Re: Updating the demo site

[Kurt Stam]

OK I’m in after https://issues.apache.org/jira/browse/INFRA-19130 
<https://issues.apache.org/jira/browse/INFRA-19130>


So Alex should we use a PostgreSQL DB? WDYT?

Also the easiest is to get started using the preconfigured juddi-tomcat from 
juddi-distro-3.3.6.zip 
<http://apache.cs.uu.nl/juddi/juddi/3.3.6/juddi-distro-3.3.6.zip>, which 
actually has some issues on JDK8

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.io=ALL-UNNAMED 
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was 
removed in 8.0
OpenJDK 64-Bit Server VM warning: Ignoring option PermSize; support was removed 
in 8.0
-Djava.endorsed.dirs=/home/kstam/juddi-distro-3.3.6/juddi-tomcat-3.3.6/endorsed 
is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

So we either use a older JDK, or we need to release jUDDI with a newer tomcat 
version.

How do you guys want to proceed?

—Kurt

> On Sep 22, 2019, at 2:26 PM, Kurt Stam  wrote:
> 
> Don’t Bernie me: https://www.youtube.com/watch?v=VGTaE1cLyJA 
> <https://www.youtube.com/watch?v=VGTaE1cLyJA>
> 
>> On Sep 21, 2019, at 11:41 PM, Steve Viens > <mailto:svi...@gmail.com>> wrote:
>> 
>> Not Guilty! ... but good grief - I am totally guilty of negligence.  I 
>> completely forgot about this.  My apologies.
>> 
>> Steve
>> 
>> 
>> 
>> On Sat, Sep 21, 2019 at 4:23 PM Kurt Stam > <mailto:kurt.s...@gmail.com>> wrote:
>> Steve did it!
>> 
>>> On Sep 21, 2019, at 22:20, Alex O'Ree >> <mailto:spyhunte...@gmail.com>> wrote:
>>> 
>>> 
>>> did anyone delete the root business? hmmm
>>> 
>>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens >> <mailto:svi...@gmail.com>> wrote:
>>> Awesome Alex.  I’ve been buried for past two weeks and just catching up 
>>> with personal email and saw yours.  I’ll take a look as soon as I can.
>>> 
>>> Steve 
>>> 
>>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree >> <mailto:alexo...@apache.org>> wrote:
>>> good news, i got the demo set up and running
>>> 
>>> https://demo.juddi.apache.org/ <https://demo.juddi.apache.org/>
>>> some important paths
>>> /var/log/tomcat9
>>> /var/lib/tomcat9/webapps
>>> /etc/tomcat9
>>> 
>>> the original tomcat root app was moved to /opt in case we need it in the 
>>> future.
>>> ssl cert is via lets encrypt, good until oct 25th
>>> 
>>> the hard part was getting derby to fire up. it ended up at 
>>> /etc/tomcat9/Catalina/...
>>> all other locations had file permissions issues (or maybe a security 
>>> manager?)
>>> 
>>> finally the site also runs on port 80 if needed, but tls should be used 
>>> when possible.
>>> 
>>> On Sat, Jul 27, 2019 at 5:23 PM Alex O'Ree >> <mailto:alexo...@apache.org>> wrote:
>>> Steve, Kurt
>>> 
>>> Please confirm that you can sign into (via ssh) demo.juddi.apache.org 
>>> <http://demo.juddi.apache.org/>
>>> use your asf credentials. You'll also want to test sudoing. ASF infra uses 
>>> something all opie for open time passwords for sudo.
>>> Details here: 
>>> https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249
>>>  
>>> <https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249>
>>> 
>>> Anyhow, try to sign in and run 
>>> ortpasswd
>>> use the linked website to create the one time password and paste it in
>>> then run
>>> sudo apt update
>>> it should prompt for a open time password, again, repeat the process
>>> 
>>> On Tue, Jun 18, 2019 at 5:33 PM Steve Viens >> <mailto:svi...@gmail.com>> wrote:
>>> I’ll volunteer!  Sign me up.  
>>> 
>>> Steve
>>> 
>>> On Tue, Jun 18, 2019 at 5:26 PM Alex O'Ree >> <mailto:spyhunte...@gmail.com>> wrote:
>>> Thanks Kurt!
>>> 
>>> Just need one more person to act as a backup
>>> 
>>> On Tue, Jun 18, 2019 at 10:30 AM Kurt Stam >> <mailto:kurt.s...@gmail.com>>

Re: Updating the demo site

[Kurt Stam]

Don’t Bernie me: https://www.youtube.com/watch?v=VGTaE1cLyJA

> On Sep 21, 2019, at 11:41 PM, Steve Viens  wrote:
> 
> Not Guilty! ... but good grief - I am totally guilty of negligence.  I 
> completely forgot about this.  My apologies.
> 
> Steve
> 
> 
> 
> On Sat, Sep 21, 2019 at 4:23 PM Kurt Stam  <mailto:kurt.s...@gmail.com>> wrote:
> Steve did it!
> 
>> On Sep 21, 2019, at 22:20, Alex O'Ree > <mailto:spyhunte...@gmail.com>> wrote:
>> 
>> 
>> did anyone delete the root business? hmmm
>> 
>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens > <mailto:svi...@gmail.com>> wrote:
>> Awesome Alex.  I’ve been buried for past two weeks and just catching up with 
>> personal email and saw yours.  I’ll take a look as soon as I can.
>> 
>> Steve 
>> 
>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree > <mailto:alexo...@apache.org>> wrote:
>> good news, i got the demo set up and running
>> 
>> https://demo.juddi.apache.org/ <https://demo.juddi.apache.org/>
>> some important paths
>> /var/log/tomcat9
>> /var/lib/tomcat9/webapps
>> /etc/tomcat9
>> 
>> the original tomcat root app was moved to /opt in case we need it in the 
>> future.
>> ssl cert is via lets encrypt, good until oct 25th
>> 
>> the hard part was getting derby to fire up. it ended up at 
>> /etc/tomcat9/Catalina/...
>> all other locations had file permissions issues (or maybe a security 
>> manager?)
>> 
>> finally the site also runs on port 80 if needed, but tls should be used when 
>> possible.
>> 
>> On Sat, Jul 27, 2019 at 5:23 PM Alex O'Ree > <mailto:alexo...@apache.org>> wrote:
>> Steve, Kurt
>> 
>> Please confirm that you can sign into (via ssh) demo.juddi.apache.org 
>> <http://demo.juddi.apache.org/>
>> use your asf credentials. You'll also want to test sudoing. ASF infra uses 
>> something all opie for open time passwords for sudo.
>> Details here: 
>> https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249
>>  
>> <https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249>
>> 
>> Anyhow, try to sign in and run 
>> ortpasswd
>> use the linked website to create the one time password and paste it in
>> then run
>> sudo apt update
>> it should prompt for a open time password, again, repeat the process
>> 
>> On Tue, Jun 18, 2019 at 5:33 PM Steve Viens > <mailto:svi...@gmail.com>> wrote:
>> I’ll volunteer!  Sign me up.  
>> 
>> Steve
>> 
>> On Tue, Jun 18, 2019 at 5:26 PM Alex O'Ree > <mailto:spyhunte...@gmail.com>> wrote:
>> Thanks Kurt!
>> 
>> Just need one more person to act as a backup
>> 
>> On Tue, Jun 18, 2019 at 10:30 AM Kurt Stam > <mailto:kurt.s...@gmail.com>> wrote:
>> Hi Alex,
>> 
>> I can help. 
>> 
>> Cheers,
>> 
>> —Kurt
>> 
>> > On Jun 15, 2019, at 4:57 PM, Alex O'Ree > > <mailto:alexo...@apache.org>> wrote:
>> > 
>> > Dear jUDDI enthusiasts,
>> > 
>> > We used to have a "gear" in the redhat cloud that hosted a demo instance 
>> > of juddi. I'm not too sure what happened but i think it either expired or 
>> > redhat turned them all off or whatever and migrated to something else. 
>> > Regardless, that instance has been dead for a while.
>> > 
>> > Moving forward, i've asked the ASF infra team if they have a solution. The 
>> > answer is yes, they can fire up a VM for this purpose. The only catch is 
>> > that they want to have at least 3 people be designated as maintainers of 
>> > the VM.
>> > 
>> > I'll certainly volunteer but i'll need 2 others to volunteer in order to 
>> > move forward. I would expect that time requirement by those volunteers 
>> > would be super minimal, every now and again type of thing. It'll be an 
>> > ubuntu vm.
>> > 
>> > Anyone out there want to help?
>> 
>> 
>> -- 
>> Steve Viens
>> svi...@gmail.com <mailto:svi...@gmail.com>
>> 603-828-2397
>> -- 
>> Steve Viens
>> svi...@gmail.com <mailto:svi...@gmail.com>
>> 603-828-2397

Re: Updating the demo site

[Kurt Stam]

I can take a look tomorrow 

> On Sep 21, 2019, at 23:30, Alex O'Ree  wrote:
> 
> 
> ok so i am giving up on fixing this. my linux knowledge is probably limited 
> compared to the rest of you.
> current issue: derby wont start up and complains about not being able to 
> create the db directory
> 
> ive tried everything i can think of to fix the file permissions issue. i've 
> even su tomcat to that dir and verified i can make the directory.
> 
> current state: we are setup for in memory db. so its working but is far from 
> ideal.
> 
>> On Sat, Sep 21, 2019 at 4:38 PM Alex O'Ree  wrote:
>> i think i just never finished configuring it. the database was pointed at a 
>> readonly location on the drive...working it now
>> 
>>> On Sat, Sep 21, 2019 at 4:20 PM Alex O'Ree  wrote:
>>> did anyone delete the root business? hmmm
>>> 
>>>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens  wrote:
>>>> Awesome Alex.  I’ve been buried for past two weeks and just catching up 
>>>> with personal email and saw yours.  I’ll take a look as soon as I can.
>>>> 
>>>> Steve 
>>>> 
>>>>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree  wrote:
>>>>> good news, i got the demo set up and running
>>>>> 
>>>>> https://demo.juddi.apache.org/
>>>>> some important paths
>>>>> /var/log/tomcat9
>>>>> /var/lib/tomcat9/webapps
>>>>> /etc/tomcat9
>>>>> 
>>>>> the original tomcat root app was moved to /opt in case we need it in the 
>>>>> future.
>>>>> ssl cert is via lets encrypt, good until oct 25th
>>>>> 
>>>>> the hard part was getting derby to fire up. it ended up at 
>>>>> /etc/tomcat9/Catalina/...
>>>>> all other locations had file permissions issues (or maybe a security 
>>>>> manager?)
>>>>> 
>>>>> finally the site also runs on port 80 if needed, but tls should be used 
>>>>> when possible.
>>>>> 
>>>>>> On Sat, Jul 27, 2019 at 5:23 PM Alex O'Ree  wrote:
>>>>>> Steve, Kurt
>>>>>> 
>>>>>> Please confirm that you can sign into (via ssh) demo.juddi.apache.org
>>>>>> use your asf credentials. You'll also want to test sudoing. ASF infra 
>>>>>> uses something all opie for open time passwords for sudo.
>>>>>> Details here: 
>>>>>> https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249
>>>>>> 
>>>>>> Anyhow, try to sign in and run 
>>>>>> ortpasswd
>>>>>> use the linked website to create the one time password and paste it in
>>>>>> then run
>>>>>> sudo apt update
>>>>>> it should prompt for a open time password, again, repeat the process
>>>>>> 
>>>>>>> On Tue, Jun 18, 2019 at 5:33 PM Steve Viens  wrote:
>>>>>>> I’ll volunteer!  Sign me up.  
>>>>>>> 
>>>>>>> Steve
>>>>>>> 
>>>>>>>> On Tue, Jun 18, 2019 at 5:26 PM Alex O'Ree  
>>>>>>>> wrote:
>>>>>>>> Thanks Kurt!
>>>>>>>> 
>>>>>>>> Just need one more person to act as a backup
>>>>>>>> 
>>>>>>>>> On Tue, Jun 18, 2019 at 10:30 AM Kurt Stam  
>>>>>>>>> wrote:
>>>>>>>>> Hi Alex,
>>>>>>>>> 
>>>>>>>>> I can help. 
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> —Kurt
>>>>>>>>> 
>>>>>>>>> > On Jun 15, 2019, at 4:57 PM, Alex O'Ree  wrote:
>>>>>>>>> > 
>>>>>>>>> > Dear jUDDI enthusiasts,
>>>>>>>>> > 
>>>>>>>>> > We used to have a "gear" in the redhat cloud that hosted a demo 
>>>>>>>>> > instance of juddi. I'm not too sure what happened but i think it 
>>>>>>>>> > either expired or redhat turned them all off or whatever and 
>>>>>>>>> > migrated to something else. Regardless, that instance has been dead 
>>>>>>>>> > for a while.
>>>>>>>>> > 
>>>>>>>>> > Moving forward, i've asked the ASF infra team if they have a 
>>>>>>>>> > solution. The answer is yes, they can fire up a VM for this 
>>>>>>>>> > purpose. The only catch is that they want to have at least 3 people 
>>>>>>>>> > be designated as maintainers of the VM.
>>>>>>>>> > 
>>>>>>>>> > I'll certainly volunteer but i'll need 2 others to volunteer in 
>>>>>>>>> > order to move forward. I would expect that time requirement by 
>>>>>>>>> > those volunteers would be super minimal, every now and again type 
>>>>>>>>> > of thing. It'll be an ubuntu vm.
>>>>>>>>> > 
>>>>>>>>> > Anyone out there want to help?
>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> -- 
>>>>>>> Steve Viens
>>>>>>> svi...@gmail.com
>>>>>>> 603-828-2397
>>>> -- 
>>>> Steve Viens
>>>> svi...@gmail.com
>>>> 603-828-2397

Re: Updating the demo site

[Kurt Stam]

Steve did it!

> On Sep 21, 2019, at 22:20, Alex O'Ree  wrote:
> 
> 
> did anyone delete the root business? hmmm
> 
>> On Wed, Jul 31, 2019 at 11:55 AM Steve Viens  wrote:
>> Awesome Alex.  I’ve been buried for past two weeks and just catching up with 
>> personal email and saw yours.  I’ll take a look as soon as I can.
>> 
>> Steve 
>> 
>>> On Sat, Jul 27, 2019 at 8:47 PM Alex O'Ree  wrote:
>>> good news, i got the demo set up and running
>>> 
>>> https://demo.juddi.apache.org/
>>> some important paths
>>> /var/log/tomcat9
>>> /var/lib/tomcat9/webapps
>>> /etc/tomcat9
>>> 
>>> the original tomcat root app was moved to /opt in case we need it in the 
>>> future.
>>> ssl cert is via lets encrypt, good until oct 25th
>>> 
>>> the hard part was getting derby to fire up. it ended up at 
>>> /etc/tomcat9/Catalina/...
>>> all other locations had file permissions issues (or maybe a security 
>>> manager?)
>>> 
>>> finally the site also runs on port 80 if needed, but tls should be used 
>>> when possible.
>>> 
>>>> On Sat, Jul 27, 2019 at 5:23 PM Alex O'Ree  wrote:
>>>> Steve, Kurt
>>>> 
>>>> Please confirm that you can sign into (via ssh) demo.juddi.apache.org
>>>> use your asf credentials. You'll also want to test sudoing. ASF infra uses 
>>>> something all opie for open time passwords for sudo.
>>>> Details here: 
>>>> https://issues.apache.org/jira/browse/INFRA-18617?focusedCommentId=16893249=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16893249
>>>> 
>>>> Anyhow, try to sign in and run 
>>>> ortpasswd
>>>> use the linked website to create the one time password and paste it in
>>>> then run
>>>> sudo apt update
>>>> it should prompt for a open time password, again, repeat the process
>>>> 
>>>>> On Tue, Jun 18, 2019 at 5:33 PM Steve Viens  wrote:
>>>>> I’ll volunteer!  Sign me up.  
>>>>> 
>>>>> Steve
>>>>> 
>>>>>> On Tue, Jun 18, 2019 at 5:26 PM Alex O'Ree  wrote:
>>>>>> Thanks Kurt!
>>>>>> 
>>>>>> Just need one more person to act as a backup
>>>>>> 
>>>>>>> On Tue, Jun 18, 2019 at 10:30 AM Kurt Stam  wrote:
>>>>>>> Hi Alex,
>>>>>>> 
>>>>>>> I can help. 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> —Kurt
>>>>>>> 
>>>>>>> > On Jun 15, 2019, at 4:57 PM, Alex O'Ree  wrote:
>>>>>>> > 
>>>>>>> > Dear jUDDI enthusiasts,
>>>>>>> > 
>>>>>>> > We used to have a "gear" in the redhat cloud that hosted a demo 
>>>>>>> > instance of juddi. I'm not too sure what happened but i think it 
>>>>>>> > either expired or redhat turned them all off or whatever and migrated 
>>>>>>> > to something else. Regardless, that instance has been dead for a 
>>>>>>> > while.
>>>>>>> > 
>>>>>>> > Moving forward, i've asked the ASF infra team if they have a 
>>>>>>> > solution. The answer is yes, they can fire up a VM for this purpose. 
>>>>>>> > The only catch is that they want to have at least 3 people be 
>>>>>>> > designated as maintainers of the VM.
>>>>>>> > 
>>>>>>> > I'll certainly volunteer but i'll need 2 others to volunteer in order 
>>>>>>> > to move forward. I would expect that time requirement by those 
>>>>>>> > volunteers would be super minimal, every now and again type of thing. 
>>>>>>> > It'll be an ubuntu vm.
>>>>>>> > 
>>>>>>> > Anyone out there want to help?
>>> 
>>>>>>> 
>>>>>>> 
>>>>> -- 
>>>>> Steve Viens
>>>>> svi...@gmail.com
>>>>> 603-828-2397
>> -- 
>> Steve Viens
>> svi...@gmail.com
>> 603-828-2397

Re: Updating the demo site

[Kurt Stam]

Hi Alex,

I can help. 

Cheers,

—Kurt

> On Jun 15, 2019, at 4:57 PM, Alex O'Ree  wrote:
> 
> Dear jUDDI enthusiasts,
> 
> We used to have a "gear" in the redhat cloud that hosted a demo instance of 
> juddi. I'm not too sure what happened but i think it either expired or redhat 
> turned them all off or whatever and migrated to something else. Regardless, 
> that instance has been dead for a while.
> 
> Moving forward, i've asked the ASF infra team if they have a solution. The 
> answer is yes, they can fire up a VM for this purpose. The only catch is that 
> they want to have at least 3 people be designated as maintainers of the VM.
> 
> I'll certainly volunteer but i'll need 2 others to volunteer in order to move 
> forward. I would expect that time requirement by those volunteers would be 
> super minimal, every now and again type of thing. It'll be an ubuntu vm.
> 
> Anyone out there want to help?

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Kurt Stam]

+1 from me too

Where will we move to? Github or gitbox.apache.org ?

> On Dec 8, 2018, at 5:09 PM, Alex O'Ree  wrote:
> 
> Juddi devs, I got this from infra yesterday and it does apply to both juddi 
> and scout. It sounds like it will be a minimal impact besides updating some 
> links on the website and poms. 
> All those in favor of moving during the voluntary time period, vote +1 
> otherwise state your intentions. 
> 
> +1 for the voluntary period for me.
> 
> 
> -- Forwarded message -
> From: Daniel Gruno mailto:humbed...@apache.org>>
> Date: Fri, Dec 7, 2018, 11:52 AM
> Subject: [NOTICE] Mandatory relocation of Apache git repositories on 
> git-wip-us.apache.org 
> To: us...@infra.apache.org  
> mailto:us...@infra.apache.org>>
> 
> 
> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
>   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> 
> Hello Apache projects,
> 
> I am writing to you because you may have git repositories on the
> git-wip-us server, which is slated to be decommissioned in the coming
> months. All repositories will be moved to the new gitbox service which
> includes direct write access on github as well as the standard ASF
> commit access via gitbox.apache.org .
> 
> ## Why this move? ##
> The move comes as a result of retiring the git-wip service, as the
> hardware it runs on is longing for retirement. In lieu of this, we
> have decided to consolidate the two services (git-wip and gitbox), to
> ease the management of our repository systems and future-proof the
> underlying hardware. The move is fully automated, and ideally, nothing
> will change in your workflow other than added features and access to
> GitHub.
> 
> ## Timeframe for relocation ##
> Initially, we are asking that projects voluntarily request to move
> their repositories to gitbox, hence this email. The voluntary
> timeframe is between now and January 9th 2019, during which projects
> are free to either move over to gitbox or stay put on git-wip. After
> this phase, we will be requiring the remaining projects to move within
> one month, after which we will move the remaining projects over.
> 
> To have your project moved in this initial phase, you will need:
> 
> - Consensus in the project (documented via the mailing list)
> - File a JIRA ticket with INFRA to voluntarily move your project repos
>over to gitbox (as stated, this is highly automated and will take
>between a minute and an hour, depending on the size and number of
>your repositories)
> 
> To sum up the preliminary timeline;
> 
> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
>relocation
> - January 9th -> February 6th: Mandated (coordinated) relocation
> - February 7th: All remaining repositories are mass migrated.
> 
> This timeline may change to accommodate various scenarios.
> 
> ## Using GitHub with ASF repositories ##
> When your project has moved, you are free to use either the ASF
> repository system (gitbox.apache.org ) OR GitHub 
> for your development
> and code pushes. To be able to use GitHub, please follow the primer
> at: https://reference.apache.org/committer/github 
> 
> 
> 
> We appreciate your understanding of this issue, and hope that your
> project can coordinate voluntarily moving your repositories in a
> timely manner.
> 
> All settings, such as commit mail targets, issue linking, PR
> notification schemes etc will automatically be migrated to gitbox as
> well.
> 
> With regards, Daniel on behalf of ASF Infra.
> 
> PS:For inquiries, please reply to us...@infra.apache.org 
> , not your 
> project's dev list :-).
> 
> 

Re: [VOTE] SCOUT v1.2.8

[Kurt Stam]

+1 cheers —Kurt

On Dec 8, 2018, at 17:10, Alex O'Ree  wrote:

That's a +1 from me as well. We are at about 72 hours. Anyone else care to
vote?

On Wed, Dec 5, 2018 at 11:04 PM Steve Viens  wrote:

> +1
>
> Steve Viens
> svi...@gmail.com
> 603-828-2397
>
>
> On Wed, Dec 5, 2018 at 3:00 PM Alex O'Ree  wrote:
>
>> Dear jUDDI enthusiasts,
>>
>> The new release for SCOUT is here! This release resolves 5 JIRAs, most of
>> them are bug fixes and maintenance related issues. It also resolves several
>> issues that were introduced when resolving UDDI spec adherence with jUDDI
>> 3.1.5 that were never retested with SCOUT. The largest change was related
>> to JXR Address to UDDI Addressline line mappings which may cause some
>> issues if upgrading.
>>
>> The release distribution is temporarily available here (without hashes)
>>
>> https://www.dropbox.com/sh/v4patewpkybo8an/AABWquVy2IUxBo1NPEJr_I_3a?dl=0
>>
>>
>> The release artifacts are staged in nexus:
>> *https://repository.apache.org/content/repositories/orgapachejuddi-1016
>> *
>>
>> and we have a tag at:
>> *https://git-wip-us.apache.org/repos/asf?p=juddi-scout.git;a=log;h=refs/tags/scout-1.2.8
>> *
>>
>>
>> Please give it a spin and cast your vote. This vote will be open for
>> the next 72 hours per the release policy, which is:
>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>> votes are received with no -1 vote being cast, or
>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing
>> that
>>  - after 72h provided at least 3 +1 votes have been cast and there is
>> a majority of +1 votes from the cast votes.
>> Bug
>>
>>- [SCOUT-132 ] - Bad
>>string generation for logs/exceptions
>>- [SCOUT-133 ] -
>>Website lists 1.2.6 as the latest version, however there is a tag and a
>>release for 1.2.7
>>- [SCOUT-134 ] -
>>Scout runs integration tests against a very old version of jUDDI, running
>>against the current causes compile errors and unit test failures
>>- [SCOUT-135 ] -
>>Incorrect mappings for UDDI Address line
>>- [SCOUT-136 ] -
>>Scout adds sort by name desc to findBinding UDDI requests, which is 
>> invalid
>>
>>

Re: [VOTE] jUDDI v3.3.6 (second attempt)

[Kurt Stam]

BTW you forgot to vote yourself :)

> On Dec 2, 2018, at 7:37 PM, Alex O'Ree  wrote:
> 
> Dear jUDDI enthusiasts,
> 
> The new release is here! This release resolves 4 JIRAs, 2 tasks and 2 bug 
> fixes related to incorrect logic of the findBinding API and some line ending 
> issues with bash scripts. The API bug was preventing updates to the SCOUT 
> project. Once this release is complete, then we can cut a new version of 
> SCOUT. The release notes file is missing the bash script issue but other than 
> that, it should be good to go.
> 
> The release distribution is temporarily available here (without hashes)
> https://www.dropbox.com/sh/4rsd8o78nib8o7s/AABjmEhGK4PAYLSDnYj5x6tba?dl=0 
> 
> 
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1014 
>   
> 
> and we have a tag at:
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6
>  
> r2
> 
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
> 
> Bug
> [JUDDI-992 ] - FindBinding 
> API call doesn't exactly match the spec, can't search for just the service key
> [JUDDI-994 ] - Bash scripts 
> containing windows CRLF line endings
> Improvement
> [JUDDI-988 ] - Update to 
> tomcat 9
> Task
> [JUDDI-962 ] - Convert 
> juddi.apache.org  back to mvn site

Re: [VOTE] jUDDI v3.3.6 (second attempt)

[Kurt Stam]

+1

> On Dec 3, 2018, at 3:58 AM, Steve Viens  wrote:
> 
> +1
> 
> On Sun, Dec 2, 2018 at 5:45 PM Anil Saldanha  > wrote:
> +1
> 
> ~~
> 
> On Dec 2, 2018, at 12:37 PM, Alex O'Ree  > wrote:
> 
>> Dear jUDDI enthusiasts,
>> 
>> The new release is here! This release resolves 4 JIRAs, 2 tasks and 2 bug 
>> fixes related to incorrect logic of the findBinding API and some line ending 
>> issues with bash scripts. The API bug was preventing updates to the SCOUT 
>> project. Once this release is complete, then we can cut a new version of 
>> SCOUT. The release notes file is missing the bash script issue but other 
>> than that, it should be good to go.
>> 
>> The release distribution is temporarily available here (without hashes)
>> https://www.dropbox.com/sh/4rsd8o78nib8o7s/AABjmEhGK4PAYLSDnYj5x6tba?dl=0 
>> 
>> 
>> The release artifacts are staged in nexus:
>> https://repository.apache.org/content/repositories/orgapachejuddi-1014 
>>   
>> 
>> and we have a tag at:
>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6
>>  
>> r2
>> 
>> Please give it a spin and cast your vote. This vote will be open for
>> the next 72 hours per the release policy, which is:
>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>> votes are received with no -1 vote being cast, or
>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>>  - after 72h provided at least 3 +1 votes have been cast and there is
>> a majority of +1 votes from the cast votes.
>> 
>> Bug
>> [JUDDI-992 ] - FindBinding 
>> API call doesn't exactly match the spec, can't search for just the service 
>> key
>> [JUDDI-994 ] - Bash scripts 
>> containing windows CRLF line endings
>> Improvement
>> [JUDDI-988 ] - Update to 
>> tomcat 9
>> Task
>> [JUDDI-962 ] - Convert 
>> juddi.apache.org  back to mvn site
> -- 
> Steve Viens
> svi...@gmail.com 
> 603-828-2397

Re: [VOTE] jUDDI-3.3.6

[Kurt Stam]

Hi Alex,

Looks all ok now. We need to do one last thing which is verifying that the key 
belongs to you. How about a quick Skype call and you show my some form of ID, 
and read the fingerprint back to me. 

I will then sign your key.

Cheers,

—Kurt

gpg: Good signature from "Alex O'Ree " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3A1A AFA9 B89A 1D1D DD5F  3A4B 98AD 2E19 BFF4 106D

> On Nov 27, 2018, at 12:35 AM, Alex O'Ree  wrote:
> 
> Kurt,
> I just pushed the KEYS file again and made sure my new key was added to the 
> MIT and SKS server. Can you give it a try when you have a second?
> 
> On Mon, Nov 26, 2018 at 1:16 PM Kurt Stam  <mailto:kurt.s...@gmail.com>> wrote:
> I double checked and also imported the keys from the KEYS file on master with 
> the same result. —Kurt
> 
>> On Nov 26, 2018, at 6:42 PM, Alex O'Ree > <mailto:alexo...@apache.org>> wrote:
>> 
>> Not at that url. It's a new key. It should be in the source repo.
>> 
>> On Mon, Nov 26, 2018, 10:35 AM Kurt Stam > <mailto:kurt.s...@gmail.com> wrote:
>> There also seems to be an issue with your key not being public:
>> 
>>  gpg --verify juddi-distro-3.3.6.zip.asc 
>> gpg: assuming signed data in 'juddi-distro-3.3.6.zip'
>> gpg: Signature made Sat Nov 24 16:52:18 2018 CET
>> gpg:using RSA key 3A1AAFA9B89A1D1DDD5F3A4B98AD2E19BFF4106D
>> gpg: Can't check signature: No public key
>> 
>> Note that I’ve important all KEYS from 
>> https://www.apache.org/dist/juddi/KEYS 
>> <https://www.apache.org/dist/juddi/KEYS>
>> 
>> Did you upload the latest key you used?
>> 
>> —Kurt
>> 
>>> On Nov 26, 2018, at 4:16 PM, Alex O'Ree >> <mailto:alexo...@apache.org>> wrote:
>>> 
>>> Bugger. Stupid line endings.  Easiest thing is a readme.
>>> 
>>> On Mon, Nov 26, 2018, 5:39 AM Kurt Stam >> <mailto:kurt.s...@gmail.com> wrote:
>>> Hi Alex,
>>> 
>>> The file format of the juddi-distro-3.3.6/juddi-tomcat-3.3.6/bin/catalina.sh
>>> 
>>> Is not unix, so it won’t startup tomcat. What do you prefer, adding 
>>> something to the release notes or do you want to respin the release?
>>> 
>>> Cheers,
>>> 
>>> —Kurt
>>> 
>>>> On Nov 24, 2018, at 8:53 PM, Alex O'Ree >>> <mailto:alexo...@apache.org>> wrote:
>>>> 
>>>> Dear jUDDI enthusiasts,
>>>> 
>>>> The new release is here! This release resolves 3 JIRAs, 2 tasks and a bug 
>>>> fix related to incorrect logic of the findBinding API. The bug was 
>>>> preventing updates to the SCOUT project. Once this release is complete 
>>>> (and I finally get commit permissions on SCOUT), then we can cut a new 
>>>> version of SCOUT. 
>>>> 
>>>> The release distribution is temporarily available here (without hashes)
>>>> https://www.dropbox.com/sh/loyuchxtxg0zrwq/AAA4nqh9rUBEXiRQ7JK43fl6a?dl=0 
>>>> <https://www.dropbox.com/sh/loyuchxtxg0zrwq/AAA4nqh9rUBEXiRQ7JK43fl6a?dl=0>
>>>> 
>>>> The release artifacts are staged in nexus:
>>>> https://repository.apache.org/content/repositories/orgapachejuddi-1013/ 
>>>> <https://repository.apache.org/content/repositories/orgapachejuddi-1013/>
>>>> 
>>>> and we have a tag at:
>>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6
>>>>  
>>>> <https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6>
>>>> 
>>>> Please give it a spin and cast your vote. This vote will be open for
>>>> the next 72 hours per the release policy, which is:
>>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>>> votes are received with no -1 vote being cast, or
>>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>>> that
>>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>>> a majority of +1 votes from the cast votes.
>>>> 
>>>> Bug
>>>> [JUDDI-992 <https://issues.apache.org/jira/browse/JUDDI-992>] - 
>>>> FindBinding API call doesn't exactly match the spec, can't search for just 
>>>> the service key
>>>> Improvement
>>>> [JUDDI-988 <https://issues.apache.org/jira/browse/JUDDI-988>] - Update to 
>>>> tomcat 9
>>>> Task
>>>> [JUDDI-962 <https://issues.apache.org/jira/browse/JUDDI-962>] - Convert 
>>>> juddi.apache.org <http://juddi.apache.org/> back to mvn site
>>> 
>> 
> 

Re: [VOTE] jUDDI-3.3.6

[Kurt Stam]

I double checked and also imported the keys from the KEYS file on master with 
the same result. —Kurt

> On Nov 26, 2018, at 6:42 PM, Alex O'Ree  wrote:
> 
> Not at that url. It's a new key. It should be in the source repo.
> 
> On Mon, Nov 26, 2018, 10:35 AM Kurt Stam  <mailto:kurt.s...@gmail.com> wrote:
> There also seems to be an issue with your key not being public:
> 
>  gpg --verify juddi-distro-3.3.6.zip.asc 
> gpg: assuming signed data in 'juddi-distro-3.3.6.zip'
> gpg: Signature made Sat Nov 24 16:52:18 2018 CET
> gpg:using RSA key 3A1AAFA9B89A1D1DDD5F3A4B98AD2E19BFF4106D
> gpg: Can't check signature: No public key
> 
> Note that I’ve important all KEYS from 
> https://www.apache.org/dist/juddi/KEYS 
> <https://www.apache.org/dist/juddi/KEYS>
> 
> Did you upload the latest key you used?
> 
> —Kurt
> 
>> On Nov 26, 2018, at 4:16 PM, Alex O'Ree > <mailto:alexo...@apache.org>> wrote:
>> 
>> Bugger. Stupid line endings.  Easiest thing is a readme.
>> 
>> On Mon, Nov 26, 2018, 5:39 AM Kurt Stam > <mailto:kurt.s...@gmail.com> wrote:
>> Hi Alex,
>> 
>> The file format of the juddi-distro-3.3.6/juddi-tomcat-3.3.6/bin/catalina.sh
>> 
>> Is not unix, so it won’t startup tomcat. What do you prefer, adding 
>> something to the release notes or do you want to respin the release?
>> 
>> Cheers,
>> 
>> —Kurt
>> 
>>> On Nov 24, 2018, at 8:53 PM, Alex O'Ree >> <mailto:alexo...@apache.org>> wrote:
>>> 
>>> Dear jUDDI enthusiasts,
>>> 
>>> The new release is here! This release resolves 3 JIRAs, 2 tasks and a bug 
>>> fix related to incorrect logic of the findBinding API. The bug was 
>>> preventing updates to the SCOUT project. Once this release is complete (and 
>>> I finally get commit permissions on SCOUT), then we can cut a new version 
>>> of SCOUT. 
>>> 
>>> The release distribution is temporarily available here (without hashes)
>>> https://www.dropbox.com/sh/loyuchxtxg0zrwq/AAA4nqh9rUBEXiRQ7JK43fl6a?dl=0 
>>> <https://www.dropbox.com/sh/loyuchxtxg0zrwq/AAA4nqh9rUBEXiRQ7JK43fl6a?dl=0>
>>> 
>>> The release artifacts are staged in nexus:
>>> https://repository.apache.org/content/repositories/orgapachejuddi-1013/ 
>>> <https://repository.apache.org/content/repositories/orgapachejuddi-1013/>
>>> 
>>> and we have a tag at:
>>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6
>>>  
>>> <https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6>
>>> 
>>> Please give it a spin and cast your vote. This vote will be open for
>>> the next 72 hours per the release policy, which is:
>>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>>> votes are received with no -1 vote being cast, or
>>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing 
>>> that
>>>  - after 72h provided at least 3 +1 votes have been cast and there is
>>> a majority of +1 votes from the cast votes.
>>> 
>>> Bug
>>> [JUDDI-992 <https://issues.apache.org/jira/browse/JUDDI-992>] - FindBinding 
>>> API call doesn't exactly match the spec, can't search for just the service 
>>> key
>>> Improvement
>>> [JUDDI-988 <https://issues.apache.org/jira/browse/JUDDI-988>] - Update to 
>>> tomcat 9
>>> Task
>>> [JUDDI-962 <https://issues.apache.org/jira/browse/JUDDI-962>] - Convert 
>>> juddi.apache.org <http://juddi.apache.org/> back to mvn site
>> 
> 

Re: [VOTE] jUDDI-3.3.6

[Kurt Stam]

Hi Alex,

The file format of the juddi-distro-3.3.6/juddi-tomcat-3.3.6/bin/catalina.sh

Is not unix, so it won’t startup tomcat. What do you prefer, adding something 
to the release notes or do you want to respin the release?

Cheers,

—Kurt

> On Nov 24, 2018, at 8:53 PM, Alex O'Ree  wrote:
> 
> Dear jUDDI enthusiasts,
> 
> The new release is here! This release resolves 3 JIRAs, 2 tasks and a bug fix 
> related to incorrect logic of the findBinding API. The bug was preventing 
> updates to the SCOUT project. Once this release is complete (and I finally 
> get commit permissions on SCOUT), then we can cut a new version of SCOUT. 
> 
> The release distribution is temporarily available here (without hashes)
> https://www.dropbox.com/sh/loyuchxtxg0zrwq/AAA4nqh9rUBEXiRQ7JK43fl6a?dl=0 
> 
> 
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1013/ 
> 
> 
> and we have a tag at:
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.6
>  
> 
> 
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
> 
> Bug
> [JUDDI-992 ] - FindBinding 
> API call doesn't exactly match the spec, can't search for just the service key
> Improvement
> [JUDDI-988 ] - Update to 
> tomcat 9
> Task
> [JUDDI-962 ] - Convert 
> juddi.apache.org  back to mvn site

Re: [VOTE] convert juddi back to mvn site

[Kurt Stam]

+1 for mvn site.

—Kurt

> On Feb 9, 2018, at 9:14 AM, Alex O'Ree  wrote:
> 
> A while ago, we switched from a maven based site to the Apache CMS based 
> site. There are some pros and cons of this setup.
> 
> Pros (for using CMS over mvn site)
> - Site can be updated at any point in time, independent of maven builds
> - Builds are usually very quick and do not require
> 
> Cons
> - Source control is not in the main repository. As a committer, i need to 
> have 5 repos checked out pretty much all the time.
> 
> So I'm proposing that we which back to a maven based site. I've already done 
> the work and the source is up to date with what is currently on 
> juddi.apache.org . There will be some minor 
> formatting differences but for the most part the change is minimal. Assuming 
> the vote passes, I'll open a infra ticket to start the switch
> 
> To prevent the site, simple check out our git repo, then use `mvn site`. 
> Standard voting rules apply.
> 
> +1 i'm obviously for it

Re: [VOTE] jUDDI-3.3.5

[Kurt Stam]

+1 from me. 

Plus I think you forgot to vote yourself Alex :).

Cheers!

—Kurt

> On Nov 11, 2017, at 8:26 PM, Alex O'Ree  wrote:
> 
> Dear jUDDI enthusiasts,
> 
> The new release is here! This release resolves 23 JIRAs, primarily bug fixes 
> and resolves several security related issues.
> 
> The release distribution is temporarily available here
> https://www.dropbox.com/sh/4j3n8z1c0ssbn0v/AACOs0pyLdQQW2HQ0JI52ToWa?dl=0 
> 
> 
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1011 
> 
> 
> and we have a tag at:
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.
>  
> 5
> 
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>  - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
> Bug
> [JUDDI-904 ] - intermittent 
> test failures
> [JUDDI-943 ] - WebHelper 
> class: Client name not set in servletContext after getUDDIClient is called
> [JUDDI-948 ] - 
> API_070_FindEntityTest is not passing anymore
> [JUDDI-957 ] - Integration 
> test not passing. 
> org.apache.juddi.v3.tck.UDDI_070_FindEntityIntegrationTest:findSignedEntities()
> [JUDDI-960 ] - TCK tests not 
> passing (windows 7, java 1.8)
> [JUDDI-970 ] - Code smell 
> that ignores InvalidValueException
> [JUDDI-975 ] - mvn site is 
> broken
> [JUDDI-977 ] - reduce 
> findbugs warnings
> [JUDDI-978 ] - Build 
> instability with Replication tests
> [JUDDI-983 ] - Unable to 
> compile under centos, openjdk8, sun.security.provider.certpath.OCSP api 
> mismatch
> [JUDDI-984 ] - Hibernate 
> profile fails to deploy due to extraneous class in the orm xml file
> [JUDDI-985 ] - Replication 
> change record delete fails with hibernate
> [JUDDI-987 ] - TBD
> Improvement
> [JUDDI-955 ] - Pom 
> maintenance
> [JUDDI-974 ] - Add findbugs 
> to the site reporting tasks
> [JUDDI-979 ] - Add maven 
> enforcer rules
> [JUDDI-980 ] - Update 
> juddi's parent pom to the latest apache pom
> [JUDDI-981 ] - Force all 
> tests to run in a random order
> [JUDDI-986 ] - Update 
> hibernate dependencies
> Task
> [JUDDI-971 ] - Update 
> embedded tomcat to a more recent version
> [JUDDI-973 ] - Code clean up 
> juddi-client-cli
> [JUDDI-976 ] - Add jacoco 
> test results to mvn site
> [JUDDI-982 ] - Removing the 
> juddi-client-plugins module
> 
> 
> 

Re: [VOTE] jUDDI-3.3.5

[Kurt Stam]

Hi Alex, I don’t think you only count business days. Let me take a look 
tonight! Thx for keeping pushing the project forward!

—Kurt

> On Nov 14, 2017, at 19:46, Alex O'Ree  wrote:
> 
> 3 days and not a single vote. Perhaps I wasn't clear enough. This set of 
> fixes resolves a number of security issues.
> 
> Is it time to retire this project?
> 
> I don't mine maintaining it but ASF is committee driven and has pretty 
> specific rules. A passing vote is required for release and we can't get 
> enough votes for a release that resolves security issues, we'll have to move 
> this to the attic.
> 
>> On Sat, Nov 11, 2017 at 8:26 PM, Alex O'Ree  wrote:
>> Dear jUDDI enthusiasts,
>> 
>> The new release is here! This release resolves 23 JIRAs, primarily bug fixes 
>> and resolves several security related issues.
>> 
>> The release distribution is temporarily available here
>> https://www.dropbox.com/sh/4j3n8z1c0ssbn0v/AACOs0pyLdQQW2HQ0JI52ToWa?dl=0
>> 
>> The release artifacts are staged in nexus:
>> https://repository.apache.org/content/repositories/orgapachejuddi-1011
>> 
>> and we have a tag at:
>> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.5
>> 
>> Please give it a spin and cast your vote. This vote will be open for
>> the next 72 hours per the release policy, which is:
>> - the vote will be closed as soon as 6 hours have past and  >7 +1
>> votes are received with no -1 vote being cast, or
>>  - if after 12h >5 +1 votes have been cast with no -1 vote, or
>>  - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
>>  - after 72h provided at least 3 +1 votes have been cast and there is
>> a majority of +1 votes from the cast votes.
>> Bug
>> [JUDDI-904] - intermittent test failures
>> [JUDDI-943] - WebHelper class: Client name not set in servletContext after 
>> getUDDIClient is called
>> [JUDDI-948] - API_070_FindEntityTest is not passing anymore
>> [JUDDI-957] - Integration test not passing. 
>> org.apache.juddi.v3.tck.UDDI_070_FindEntityIntegrationTest:findSignedEntities()
>> [JUDDI-960] - TCK tests not passing (windows 7, java 1.8)
>> [JUDDI-970] - Code smell that ignores InvalidValueException
>> [JUDDI-975] - mvn site is broken
>> [JUDDI-977] - reduce findbugs warnings
>> [JUDDI-978] - Build instability with Replication tests
>> [JUDDI-983] - Unable to compile under centos, openjdk8, 
>> sun.security.provider.certpath.OCSP api mismatch
>> [JUDDI-984] - Hibernate profile fails to deploy due to extraneous class in 
>> the orm xml file
>> [JUDDI-985] - Replication change record delete fails with hibernate
>> [JUDDI-987] - TBD
>> Improvement
>> [JUDDI-955] - Pom maintenance
>> [JUDDI-974] - Add findbugs to the site reporting tasks
>> [JUDDI-979] - Add maven enforcer rules
>> [JUDDI-980] - Update juddi's parent pom to the latest apache pom
>> [JUDDI-981] - Force all tests to run in a random order
>> [JUDDI-986] - Update hibernate dependencies
>> Task
>> [JUDDI-971] - Update embedded tomcat to a more recent version
>> [JUDDI-973] - Code clean up juddi-client-cli
>> [JUDDI-976] - Add jacoco test results to mvn site
>> [JUDDI-982] - Removing the juddi-client-plugins module
>> 
>> 
>> 
> 

Re: [VOTE] Release jUDDI-3.3.1

[Kurt Stam]

+1 from me! --Kurt

> On Sep 30, 2015, at 18:24, Alex O'Ree  wrote:
>
> Dear jUDDI enthusiasts,
>
> The new release is here! This release is primarily bug fixes and the
> inclusion of the CLI client.
>
> The release distribution is temporarily available here
> https://www.dropbox.com/sh/zycq6j314gvuy52/AAAzhvpRqOXsmEQXaAiIExtBa?dl=0
>
>
> The release artifacts are staged in nexus:
> https://repository.apache.org/content/repositories/orgapachejuddi-1005/
>
> and we have a tag at:
> https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=2e8c72ce557a9b5bd673c03fc5300179fb1f2db4
>
>
> Please give it a spin and cast your vote. This vote will be open for
> the next 72 hours per the release policy, which is:
> - the vote will be closed as soon as 6 hours have past and  >7 +1
> votes are received with no -1 vote being cast, or
> - if after 12h >5 +1 votes have been cast with no -1 vote, or
> - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing that
> - after 72h provided at least 3 +1 votes have been cast and there is
> a majority of +1 votes from the cast votes.
>
>
>
> My vote, +1
>
>
> Release Notes:
>
> Bug
>
> [JUDDI-934] - jUDDI CLI client is not included in the distribution zips
> [JUDDI-935] - AdminUI/Statistics page fails to render under JDK8
>
> Improvement
>
> [JUDDI-933] - File based authentication mechanisms do not auto insert
> to the database

Re: [jira] [Created] (JUDDI-904) intermittent test failures

[Kurt Stam]

Ok I don't think the order is random though but if you want to be sure you can 
annotate them to order them


 On Jan 1, 2015, at 19:13, Alex O'Ree spyhunte...@gmail.com wrote:
 
 It's not a port conflict. I think one of the test creates an entity that 
 other tests depend on and assume are present. Most of the time it works out 
 ok, but when junit runs the tests in different orders it doesn't guarantee 
 that that item is present. Just need to track down the order and figure out 
 what the root cause is 
 
 On Thu, Jan 1, 2015 at 5:40 PM, Kurt Stam kurt.s...@gmail.com wrote:
 The test open a port. Other builds may choose the same port. Currently it 
 picks a random port to reduce the chances. Maybe we can change the interval 
 it picks a port number from. Do the logs show port conflict errors?
 
 
  On Jan 1, 2015, at 16:13, Alex O'Ree (JIRA) juddi-...@ws.apache.org 
  wrote:
 
  Alex O'Ree created JUDDI-904:
  
 
  Summary: intermittent test failures
  Key: JUDDI-904
  URL: https://issues.apache.org/jira/browse/JUDDI-904
  Project: jUDDI
   Issue Type: Bug
   Components: uddi-tck
 Affects Versions: 3.2
 Reporter: Alex O'Ree
 Assignee: Alex O'Ree
  Fix For: 3.3
 
 
  The tck test cases ran as part of the maven build occasionally fails. The 
  root cause is unknown, but it is most likely due to a logic error (failure 
  to clean up some entities) and/or (failure to create required entities for 
  the test). When the tests run, the fire order of junit tests can vary, 
  thus the cause of this issue
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.3.4#6332)
 

Re: [jira] [Created] (JUDDI-904) intermittent test failures

[Kurt Stam]

But there can be builds from other projects too no?


 On Jan 1, 2015, at 19:14, Alex O'Ree spyhunte...@gmail.com wrote:
 
 In addition, the buildbot configs are locked to prevent port conflicts. I.e. 
 only one build at a time per build server
 
 On Thu, Jan 1, 2015 at 7:13 PM, Alex O'Ree spyhunte...@gmail.com wrote:
 It's not a port conflict. I think one of the test creates an entity that 
 other tests depend on and assume are present. Most of the time it works out 
 ok, but when junit runs the tests in different orders it doesn't guarantee 
 that that item is present. Just need to track down the order and figure out 
 what the root cause is 
 
 On Thu, Jan 1, 2015 at 5:40 PM, Kurt Stam kurt.s...@gmail.com wrote:
 The test open a port. Other builds may choose the same port. Currently it 
 picks a random port to reduce the chances. Maybe we can change the interval 
 it picks a port number from. Do the logs show port conflict errors?
 
 
  On Jan 1, 2015, at 16:13, Alex O'Ree (JIRA) juddi-...@ws.apache.org 
  wrote:
 
  Alex O'Ree created JUDDI-904:
  
 
  Summary: intermittent test failures
  Key: JUDDI-904
  URL: https://issues.apache.org/jira/browse/JUDDI-904
  Project: jUDDI
   Issue Type: Bug
   Components: uddi-tck
 Affects Versions: 3.2
 Reporter: Alex O'Ree
 Assignee: Alex O'Ree
  Fix For: 3.3
 
 
  The tck test cases ran as part of the maven build occasionally fails. The 
  root cause is unknown, but it is most likely due to a logic error 
  (failure to clean up some entities) and/or (failure to create required 
  entities for the test). When the tests run, the fire order of junit tests 
  can vary, thus the cause of this issue
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.3.4#6332)
 

Re: [ANNOUNCE] Release jUDDI version 3.2.1

[Kurt Stam]

Congrats!! We should upgrade our cloud instance and maybe create a docker image 
for it


 On Dec 5, 2014, at 20:17, Alex O'Ree alexo...@apache.org wrote:
 
 jUDDI Version 3.2.1 Released
 
 Today we released jUDDI version 3.2.1! This version contains a number of bug 
 fixes and offer's enhanced functionality in the user interface for 
 interacting with tModels. This release resolved a incredible 65 jiras, as you 
 can see in the Release Notes.
 What new in version 3.2.1?
 
 Numerous enhancements to juddi-gui (web user interface) including several 
 security fixes, more internationalization support, 
 More automated unit tests and refactoring
 Database DDL files are now auto generated with each build
 Fixes for the newer versions of Hibernate
 We're now using GIT for cvs
 You can grab the release here:
 https://dist.apache.org/repos/dist/release/juddi/juddi/3.2.1/
 
 The website will be updated as soon as the ASF Infrastructure team get the 
 CMS repo up and running again.
 
 Alex

Re: Autocommit error with OpenJPA, JBoss and Oracle

[Kurt Stam]

You have to set autocommit to false. 

 On Mar 24, 2014, at 14:32, Toufic Arabi tar...@redhat.com wrote:
 
 Hi,
 
 I am seeing this error when deploying Juddiv3 to EAP 6.1.1 after building 
 from source. It seems that there is a commit that needs to happen on the 
 sequence table that is required to be create for juddiv3 to happen when the 
 auto commit is already set. I add to your SQL file the following:
 
 CREATE TABLE JUDDI_DBO..openjpa_sequence_table (ID NUMBER(4) NOT NULL, 
 SEQUENCE_VALUE NUMBER(20) default NULL, PRIMARY KEY (ID)) TABLESPACE 
 JUDDI_DATA;
 
 judd_dbo is the owner of the juddi tables and my datasource user has been 
 granted access to the tables created for juddi_dbo
 
 Here is the error. Have you all seen this before?
 
 13:49:41,287 ERROR 
 [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/juddiv3]]
  (ServerService Thread Pool -- 61) JBWEB000289: Servlet RegistryServlet threw 
 load() exception: java.sql.SQLException: You cannot commit with autocommit 
 set!
 at 
 org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:1061)
 at 
 org.jboss.jca.adapters.jdbc.WrappedConnection.commit(WrappedConnection.java:758)
 at 
 org.apache.openjpa.lib.jdbc.DelegatingConnection.commit(DelegatingConnection.java:175)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection.commit(LoggingConnectionDecorator.java:341)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.lib.jdbc.DelegatingConnection.commit(DelegatingConnection.java:175)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator$ConfiguringConnection.commit(ConfiguringConnectionDecorator.java:124)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.closeConnection(AbstractJDBCSeq.java:198)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.TableJDBCSeq$AllocateSequenceRunnable.run(TableJDBCSeq.java:918)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.TableJDBCSeq.allocateSequence(TableJDBCSeq.java:455)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.TableJDBCSeq.nextInternal(TableJDBCSeq.java:300)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:60) 
 [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:160) 
 [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:144) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:778)
  [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:493) 
 [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:762)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:600)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:803)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:621)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:589)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:505)
  [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:3028)
  [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:44) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:1042)
  [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2114) 
 [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2074) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1992) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
  [openjpa-2.2.1.jar:2.2.1]
 at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1516) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933) 
 [openjpa-2.2.1.jar:2.2.1]
 at 
 org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570)
  [openjpa-2.2.1.jar:2.2.1]
 at org.apache.juddi.config.Install.install(Install.java:135) 
 [juddi-core-openjpa-3.2.0-SNAPSHOT.jar:]
 at 
 

Re: [VOTE] Release jUDDI-3.2.0

[Kurt Stam]

It's all things client side. So I think it's ok. 

Besides we don't really have a dev guide, which IMHO is to bring people up to 
speed who want to work on jUDDI, other then the PDF with the screenshots. 

 On Feb 4, 2014, at 19:21, Alex O'Ree spyhunte...@gmail.com wrote:
 
 actually hold on.
 
 the dev guide is titled Apache jUDDI Client and GUI Guide. This is
 incorrect. It's the Apache jUDDI Client and Developer Guide
 
 On Tue, Feb 4, 2014 at 7:05 PM, Alex O'Ree spyhunte...@gmail.com wrote:
 roger that
 +1
 
 javadocs are uploading to the staging site now
 
 On Tue, Feb 4, 2014 at 9:31 AM, Tom Cunningham tcunn...@redhat.com wrote:
 
 Awesome job!
 
 +1
 
 
 On 2/4/14, 9:03 AM, Kurt T Stam wrote:
 
 Dear jUDDI enthusiasts,
 
 The new release is here! Long, long overdue and hopefully we won't go this
 long between releases again. The amount of work that when in is pretty
 incredible ( 206 jiras), the brunt of it all done by Alex. Just check out
 the release notes below!
 
 Here's are some highlights for this version 3.2
 
 A new end user interface based on Twitter's Bootstrap
 
 A new administrative user interface based on Twitter's Bootstrap with in
 browser monitoring
 
 A client side subscription callback API
 
 Client distribution package
 
 Many more examples
 
 WADL to UDDI mappings
 
 All credentials are now encryptable with command line tools
 
 Removal of the porlet services
 
 Deployment templates for Jboss EAP 6+
 
 Client side digital signature support
 
 REST style interface for Inquiry API
 
 Added many more tModels to the base install
 
 More documentation
 
 With this release have have two distros, a juddi and a uddi-client. The
 juddi-distro has the server, client and gui, the uddi-client-distro has the
 client, the gui and our TCK. Both distros are staged here:
 
 http://people.apache.org/~kstam/releases/juddi-3.2.0/
 
 The release artifacts are staged in nexus:
 
 https://repository.apache.org/content/repositories/orgapachejuddi-1001/
 
 and we have a tag at
 
 http://svn.apache.org/repos/asf/juddi/tags/juddi-3.2.0/
 
 and finally our new website is staged at:
 
 http://juddi.staging.apache.org/
 
 Please give it a spin and cast your vote. This vote will be open for the
 next 72 hours.
 
 My vote a huge +1 :)
 
 Cheers,
 
 --Kurt
 
 Sub-task
 
 [JUDDI-782] - Add v2 API
 
 Bug
 
 [JUDDI-405] - Improve LDAP integration
 [JUDDI-581] - Client side digital signature
 [JUDDI-590] - getAssertionStatusReport does not return incomplete assertions
 [JUDDI-593] - Upgrade to the latest CXF version
 [JUDDI-595] - Subscription API NPE, Validation required
 [JUDDI-596] - Subscription callback without a transport type is not
 delivered
 [JUDDI-597] - Binding template access point value is converted toLowerCase()
 [JUDDI-603] - Subscription email notifier shouldn't require mailto: prefix
 [JUDDI-606] - Subscription API does not validate on saveSubscription
 [JUDDI-610] - add canned query support in the console
 [JUDDI-615] - NPE when trying to sign an artifact
 [JUDDI-616] - Build fails on during JAR signing of DigSig Applet
 [JUDDI-619] - jUDDI API wsdl is not synchronized to the code base
 [JUDDI-620] - uddi-tck-test.jar is missing from the bundle
 [JUDDI-622] - no stack traces should be thrown in the console during test
 [JUDDI-623] - WSDL files are not syncronized with JUDDI API ws
 [JUDDI-626] - Create verbiage for WSDL/WADL import with for Juddi-gui
 [JUDDI-630] - Implement Inquiry tmodel uddi:uddi.org:findqualifier:orallkeys
 [JUDDI-631] - Add JAVA_OPTs memory settings for Windows catalina.bat
 [JUDDI-632] - New juddi user console does not display correctly in IE8
 [JUDDI-634] - juddi client's xsd is invalid
 [JUDDI-637] - Add source code documentation to UDDIClerk, UDDIClient,
 UDDIService and more
 [JUDDI-643] - Documentation pom fails
 [JUDDI-645] - NodeId config setting is not honored
 [JUDDI-646] - Configuring the node id causes the splash page to fail to
 render
 [JUDDI-649] - Error importing WSDL from juddi-gui
 [JUDDI-653] - Build fails on Ubuntu using OpenJDK
 [JUDDI-654] - Max Tries delivery count for subscription notification is not
 honored
 [JUDDI-655] - Maximum subscription results count is not honored for asynch
 notifications
 [JUDDI-662] - Name length of j3_signature_transform_data_value too long
 [JUDDI-663] - juddi-gui-disg jar signer is signing the wrong jar file
 [JUDDI-664] - Remove dependency on sun/oracle jdk
 [JUDDI-666] - revise documentation for ddl generation
 [JUDDI-667] - jUDDI should be able to run on a server not connected to the
 www
 [JUDDI-669] - Fix juddi-gui settings page
 [JUDDI-671] - Convert the uddi-samples projects maven
 [JUDDI-675] - exception throw when UDDIClient.stop is called more than once
 [JUDDI-676] - juddi-gui business editor page may not render
 [JUDDI-677] - save business does not validate business key for UDDI key
 rules
 [JUDDI-678] - juddi-gui does not trap expired auth tokens correctly
 [JUDDI-679] - juddi-gui NPE performing find 

Re: applet signing

[Kurt Stam]

Sure, what is the combined jar?

 On Oct 15, 2013, at 21:52, Alex O'Ree spyhunte...@gmail.com wrote:
 
 Kurt
 
 I think we still have an issue with the applet signing. It looks like
 its signing before building the combined jar file, resulting in a
 unsigned jar file. This breaks the digital signature applet. Could you
 look at it when you have a chance?

Re: Deprecate the jUDDI API?

[Kurt Stam]

One complication we need to address as part of this is around subscriptions 
between
jUDDI nodes, where client info is exchanged. I hear you talk about 2 things

- move the jUDDI-API to it's own module/jar (so no functional changes, but 
making dependencies more clear.
- depreciate the jUDDI API altogether and use straight DB access rather then 
going through the WebServices layer.

Which one are we talking?

--K

On May 30, 2013, at 9:57 AM, Alex O'Ree spyhunte...@gmail.com wrote:

 Admin user interface is in the works, I'm actually just starting it
 now. A lot of stuff will be borrowed some the juddi-gui mod as well as
 other existing stuff, so it should go pretty quickly. Again, we'll
 still need the code because it's primarily admin based stuff. The
 discussion is really, do end users really need access to it as a web
 service? Maybe, maybe not.
 
 TCK tests shouldn't be affected by it.
 
 On Thu, May 30, 2013 at 9:49 AM, Tom Cunningham tcunn...@redhat.com wrote:
 
 I don't see many reasons against removing the juddi-api but maybe it makes
 hemore sense to wait to remove it till a replacement is available in the
 administrative user interface? The backwards compatibility argument
 seems a lot stronger if you have a replacement in hand.
 
 Is removing it going to affect any of the tests?  I can't remember if
 any of them are using it in setup.
 
 
 
 On 5/29/13 7:50 PM, Alex O'Ree wrote:
 
 A while, I had a conversation with Kurt on IRC about possibly
 deprecating and/or removing the jUDDI API web service from the 3.2
 release. I'm personally for this decision and would suggest removing
 it (from the juddi-client and uddi-ws package) as there's isn't much
 value added to it from and end user's perspective. They are all
 administrative functions.
 
 I would suggest as follows:
 1) remove the juddi API web service references from the client and
 uddi-ws package
 2) repackage the juddi API web service client side stuff as a seperate
 jar file, just in case anyone needs backwards compatibility.
 3) continue to deploy the web service within juddi-war
 4) continue to build an administrative user interface. See JUDDI-455,
 JUDDI-579, JUDDI-607. This will greatly aid system administrators.
 These functions can simply reuse the code from jUDDI API web service
 5) finally, document the changes
 
 This is open for discussion, but I just wanted to get the ball rolling
 on this one. Any thoughts or opinions on this?
 
 

Re: javadoc

[Kurt Stam]

Use the -Papache-release profile.

On May 11, 2013, at 10:18, Alex O'Ree spyhunte...@gmail.com wrote:

 Is there a maven target for generating javadoc?

Re: how to guide for war construction?

[Kurt Stam]

Yes it is

On May 5, 2013, at 11:48, Alex O'Ree spyhunte...@gmail.com wrote:

 Thanks
 
 Is the Axis2 profile for Debry and OpenJPA? I'm working on the wiki
 docs and the readme
 
 On Sun, May 5, 2013 at 10:52 AM, Kurt T Stam kurt.s...@gmail.com wrote:
 On 5/5/13 9:34 AM, Alex O'Ree wrote:
 
 Is there a quick matrix or doc that describes how and what the options
 are for making a preconfigured war file for the various targets?
 (axis, jbossws native, etc)
 
 Yes:
 
 http://svn.apache.org/repos/asf/juddi/trunk/juddiv3-war/pom.xml
 
 A profile can be invoked using the -P flag
 
 For example:
 
 mvn package -P hibernate-jbossws-cxf
 
 The profiles have different configuration for the maven war plugin:
 
 http://maven.apache.org/plugins/maven-war-plugin/
 
 There is also a readme in the same directory.
 
 Cheers,
 
 --Kurt

Re: Writing to a file from a web app in tomcat

[Kurt Stam]

I don't know the answer to that but we are already using commons configuration, 
which lets you write back to a properties file. So you could try that for your 
properties file too. 

Or use the db?

--K

On Apr 7, 2013, at 7:58, Alex O'Ree spyhunte...@gmail.com wrote:

 I'm using the following code to read a file in META-INF
  URL prop = application.getResource(/META-INF/config.properties);
if (prop == null) {
throw new Exception(Cannot locate the configuration file.);
}
session = _session;
propertiesurl = prop;
InputStream in = prop.openStream();
Properties p = new Properties();
p.load(in);
in.close();
 
 This works in both tomcat and jboss.
 
 Then later one, I want to be able to save the changes. Using code
 similar to this
 
 FileOutputStream fos = new FileOutputStream(new 
 File(propertiesurl.toString()));
String msg=Edited at  + System.currentTimeMillis() +  by 
 + request.getRemoteUser();
 p.store(fos, msg);
fos.close();
 
 The propertiesurl.toString() method in tomcat returns a JNDI URL,
 which cannot be used using the file io api's. In Jboss, this code
 works just fine. Application.getResource returns a file:/// url.
 
 So the question is, how can get the same type of setup in Tomcat?
 (write to a file in META-INF)

Re: client side subscriptions via juddi api

[Kurt Stam]

Callback are supported, but only to WebService endpoints at the moment. It will 
call the endpoint referenced in the  binding template. I remember having an 
issue if the transport was not set to WS, there is an open Jira for that. Also 
email  callbacks are not implemented.

--K

On Apr 7, 2013, at 8:33, Alex O'Ree spyhunte...@gmail.com wrote:

 Follow up question. I found this in the UDDI spec under the
 subscription API, save subscription
 
  bindingKey:  This optional argument of type anyURI specifies the
 bindingTemplate which the node is to use to deliver notifications to
 subscription listeners.  It is only required when asynchronous
 notifications are used.  This bindingTemplate MUST define either a Web
 service that implements notify_subscriptionListener (see below), or an
 email address to receive the notifications. If a
 notify_subscriptionListener Web service is identified, the node
 invokes it to deliver notifications.  If an email address is
 identified, the node delivers notifications via email to the address
 supplied. When notifications are delivered via email, the body of the
 email contains the body of the SOAP message, which would have been
 sent to the notify_subscriptionListener service if that option had
 been chosen. The publisher making the subscription request MUST own
 the bindingTemplate.  If this argument is not supplied, no
 notifications are sent, although subscribers may still use the
 get_subscriptionResults API to obtain subscription results.  See
 Section 5.5.11get_subscriptionResults for details.  If email delivery
 to the specified address fails, nodes MAY attempt re-delivery, but are
 not obligated to do so.  Depending upon node policy, excessive
 delivery failures MAY result in cancellation of the corresponding
 subscription.
 
 The question is, is this how jUDDI is implemented? Are callbacks
 supported using this mechanism or is it only via the jUDDI API?
 
 If so, then it looks like there are two ways to setup a callback
 subscription. Use the jUDDI API method, or using the UDDI
 saveSubscription and define the binding template key representing the
 call back endpoint. (which would mean that the jUDDI api is a bit
 redundant)
 
 
 
 On Wed, Apr 3, 2013 at 12:29 PM, Kurt T Stam kurt.s...@gmail.com wrote:
 On 3/30/13 8:49 AM, Alex O'Ree wrote:
 
 With the client side subscript api from the jUDDI service, there's a
 mechanism to add a callback subscription, delete a callback
 subscription, but I don't see anything for getting a list of current
 client subscriptions, or my subscriptions.
 
 Are these subscriptions listed via the UDDI Subscription API? the unit
 test doesn't appear to cover this use case.
 
 Yeah you use:
 
 http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.3/juddi-core/src/main/java/org/apache/juddi/api/impl/UDDISubscriptionImpl.java
 
 ListSubscription getSubscriptions(
@WebParam(name = authInfo, targetNamespace =
 urn:uddi-org:api_v3)
String authInfo)
 
 which should find all subscriptions for the publisher.

Re: recommend class/method for serializing?

[Kurt Stam]

The JAX-WS layer takes care of it (using JAXB) under the hood). If you want to 
use JAXB straight up, then there is a unittest example in the uddi-ws module.

Excellent news about the digitial signature in the browser.

--K

Sent from my iPad

On Mar 24, 2013, at 10:46 AM, Alex O'Ree spyhunte...@gmail.com wrote:

 Is there a recommend class/method combo for serializing/unserializing
 uddi entity objects?
 
 I've tried using the org.apache.juddi.jaxb.PrintUDDI, however the
 output generated cannot be consumed by EntityCreator.buildFromString
 
 EntityCreate.outputEntity only prints to stdout.
 
 I almost have a digital signature functions working in the browser

Re: recommend class/method for serializing?

[Kurt Stam]

You can simply add the XMLRootElement annotation to that class you want to 
marshal. 

Sent from my iPad

On Mar 24, 2013, at 12:45 PM, Alex O'Ree spyhunte...@gmail.com wrote:

 I think i found it. org.apache.juddi.jaxb.Marshaller
 
 however now I'm getting this message.
 Caused by: com.sun.istack.SAXException2: unable to marshal type
 org.uddi.api_v3.BusinessEntity as an element because it is missing
 an @XmlRootElement annotation
 
 I've ran into this before and usually just modify the generated
 classes, however the build process is automated. Is there a way to
 sneak this into to the maven build process?
 
 On Sun, Mar 24, 2013 at 12:23 PM, Kurt Stam kurt.s...@gmail.com wrote:
 I was thinking about this one:
 
 http://svn.apache.org/repos/asf/juddi/trunk/uddi-ws/src/test/java/org/uddi/api_v3/AuthInfoTest.java
 
 --K
 
 Sent from my iPad
 
 On Mar 24, 2013, at 12:06 PM, Alex O'Ree spyhunte...@gmail.com wrote:
 
 I'm assuming you're referring to JUDDI_010 which uses EntityCreator
 Publisher pubIn = (Publisher)EntityCreator.buildFromDoc(publisherXML,
 org.apache.juddi.api_v3);
 
 The problem I have is that using  org.apache.juddi.jaxb.PrintUDDI to
 serialize, actually doesn't produce valid xml. The semantics are
 incorrect and thus cannot be used by the EntityCreator. Sounds like
 I'll just have to make one
 
 On Sun, Mar 24, 2013 at 11:44 AM, Kurt Stam kurt.s...@gmail.com wrote:
 
 The JAX-WS layer takes care of it (using JAXB) under the hood). If you want
 to use JAXB straight up, then there is a unittest example in the uddi-ws
 module.
 
 
 Excellent news about the digitial signature in the browser.
 
 
 --K
 
 
 Sent from my iPad
 
 
 On Mar 24, 2013, at 10:46 AM, Alex O'Ree spyhunte...@gmail.com wrote:
 
 
 Is there a recommend class/method combo for serializing/unserializing
 
 uddi entity objects?
 
 
 I've tried using the org.apache.juddi.jaxb.PrintUDDI, however the
 
 output generated cannot be consumed by EntityCreator.buildFromString
 
 
 EntityCreate.outputEntity only prints to stdout.
 
 
 I almost have a digital signature functions working in the browser

Re: Maven build question

[Kurt Stam]

Sure or you can run with -DskipTests=true

On Mar 23, 2013, at 14:23, Alex O'Ree spyhunte...@gmail.com wrote:

 Is there anyway to tally up all of the tests that are run at the end
 of the build and track this over time using the build bot?

Re: An observation when searching...

[Kurt Stam]

For business as well as service names the spec says:

  If a language markup is specified, the search results report a match only on 
those entries that match both the name value and language criteria. The match 
on language is a leftmost case-insensitive comparison of the characters 
supplied. This allows one to find all businesses whose name begins with an A 
and are expressed in any dialect of French, for example.  Values which can be 
passed in the language criteria adornment MUST obey the rules governing the 
xml:lang data type as defined in Section 3.3.2.3 name.

So Lang matching only comes into play when specified in the search. Only when a 
Lang is specified on the query a name without Lang setting should be omitted.

So I think we have a bug in find_services.

--Kurt

On Mar 13, 2013, at 6:43 PM, Alex O'Ree spyhunte...@gmail.com wrote:

 I just noticed that when running find_business with an
 approximateMatch and a % as a search name, business with and without
 a language value defined are returned.
 
 Find_services with the same scenario only seems to return services
 with a language defined. Services without a lang are omitted from the
 search results.
 
 The spec only talks about % applying to a few fields and lang isn't
 one of them. Does anyone recall what the 'correct' behavior is?

Re: UDDI version 3

[Kurt Stam]

Yes, try 'localhost' in stead of 'sales' unless your hosts file maps sales to 
localhost. 

--Kurt

On Mar 17, 2012, at 15:33, Fairouz Fakhfakh fairouz.fakhf...@gmail.com wrote:

 Hello,
 I use UDDI version 3,
 I tried to follow the course of this link:
 http://juddi.apache.org/docs/3.x/userguide/html/chap-Getting_Started.html#sect-using_the_tomcat_bundle
 
 I would like to publish a service. So, I try to follow the example of sales.
 But, my problem that I couldn't access to this URL: http://sales:8080/juddiv3
 The navigator is failed to find this page!
 Have you any idea about this problem, please?
 Thank you in advance.

Re: Problem in deploying war file

[Kurt Stam]

I'm not sure if you are serious with your questions..

Please study up on some basic web technology. 

On Mar 17, 2012, at 21:53, Fairouz Fakhfakh fairouz.fakhf...@gmail.com wrote:

 Hello,
 I try to deploy the juddiv3-samples.war.
 I type the command java -jar bootstrap.jar under 
 D:\juddi-tomcat-3.0.3\bin to deploy this file.
 So, a folder named juddiv3-samples-3.0.3 was created under webapps.
 I put it in D:\juddi-tomcat-3.0.3_faten_v0\webapps
 I get this folowing error:
 GRAVE: L'installation des Úcouteurs (listeners) de l'application a ÚtÚ sautÚe 
 su
 ite aux erreurs prÚcÚdentes
 18 mars 2012 01:17:39 org.apache.catalina.core.StandardContext start
 GRAVE: Error listenerStart
 18 mars 2012 01:17:39 org.apache.catalina.core.StandardContext start
 GRAVE: Erreur de dÚmarrage du contexte [/HelloWorld-20101123] suite aux 
 erreurs
 prÚcÚdentes
 log4j:WARN No appenders could be found for logger 
 (org.apache.juddi.v3.client.co
 nfig.WebHelper).
 log4j:WARN Please initialize the log4j system properly.
 I try to write http://localhost:8080/juddiv3-samples-3.0.3; in th navigator.
 But, this URL is inaccessible
 Do you have any idea about this problem, please?
 Thank you for answering me.
 
 Best regards,
 --
 Fairouz FAKHFAKH

Re: UDDI version 3

[Kurt Stam]

I'm not sure if you are serious with your questions..

Please study up on some basic web technology. 

On Mar 17, 2012, at 16:03, Fairouz Fakhfakh fairouz.fakhf...@gmail.com wrote:

 Thank you for your fast replay.
 I URL:http://localhost:8080/juddiv3/  works and displys: Welcome to Apache 
 jUDDI!..
 But, the URL:  http://sales:8080/juddiv3 does not work!!!
 My goal is to see the publication of the service sales.
 I have a question: In the file uddi.xml and exactly in this line,
 property name=serverName value=sales/
  the value of serviceName is sales or localhost?
 What can I do to resolve this problem? Or can you give me an other example of 
 publishing a service, please?
 Thank you for answering me.
 
 
 
 2012/3/17 Kurt Stam kurt.s...@gmail.com
 Yes, try 'localhost' in stead of 'sales' unless your hosts file maps sales to 
 localhost. 
 
 --Kurt
 
 
 On Mar 17, 2012, at 15:33, Fairouz Fakhfakh fairouz.fakhf...@gmail.com 
 wrote:
 
 Hello,
 I use UDDI version 3,
 I tried to follow the course of this link:
 http://juddi.apache.org/docs/3.x/userguide/html/chap-Getting_Started.html#sect-using_the_tomcat_bundle
 
 I would like to publish a service. So, I try to follow the example of 
 sales.
 But, my problem that I couldn't access to this URL: http://sales:8080/juddiv3
 The navigator is failed to find this page!
 Have you any idea about this problem, please?
 Thank you in advance.