Re: [POLL] UDDI4J on Apache?
Andy Clark wrote: It seems that Apache is becoming the W3C of implementations and this is definitely a good thing (tm). However, I wonder if the current organizational infrastructure can be scaled up as the number of Apache-hosted projects continues to increase. I have not been around the Apache community long enough to know so my worries may be ill-founded. In any case, I'm in favor of having a community based implementation of UDDI at Apache. If the number of XML projects grows too large, The XML PMC will simply bifurcate. Largely, each subproject does their own thing without a minimum of organizational interference, so this hasn't been a major concern to date. - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] UDDI4J on Apache?
+1 from me. Thanks, dims --- Ted Leung [EMAIL PROTECTED] wrote: +1 - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 7:00 AM Subject: [POLL] UDDI4J on Apache? Background: UDDI4J is an existing Open Source project, hosted on IBM DeveloperWorks and under the IBM Public License. Details, including source code, can be found at http://oss.software.ibm.com/developerworks/projects/uddi4j. More information on the specification which this code implements can be found at http://www.uddi.org/. Another company has approached IBM and expressed an interest in contributing, but expressed reservations based on where it was hosted, and requested that we consider transferring it to a neutral location. As this code complements and works closely with Apache SOAP and Axis, Apache seemed like a natural fit. This other company readily agreed. Approximately six active developers are associated with this project at this time. We expect this number would increase should it be accepted as an Apache XML subproject. General Approach: Java package names would be renamed to org.apache.uddi. All Java source files will contain headers based on the ones found in the Apache SOAP package (essentially the Apache license) The cvs repository, mailing list, and the web site will be hosted on apache.org Comments, questions, concerns? - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Davanum Srinivas - http://jguru.com/dims/ __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] UDDI4J on Apache?
+1 Anne Thomas Manes CTO, Idoox -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 10, 2001 7:01 AM To: [EMAIL PROTECTED] Subject: [POLL] UDDI4J on Apache? Background: UDDI4J is an existing Open Source project, hosted on IBM DeveloperWorks and under the IBM Public License. Details, including source code, can be found at http://oss.software.ibm.com/developerworks/projects/uddi4j. More information on the specification which this code implements can be found at http://www.uddi.org/. Another company has approached IBM and expressed an interest in contributing, but expressed reservations based on where it was hosted, and requested that we consider transferring it to a neutral location. As this code complements and works closely with Apache SOAP and Axis, Apache seemed like a natural fit. This other company readily agreed. Approximately six active developers are associated with this project at this time. We expect this number would increase should it be accepted as an Apache XML subproject. General Approach: Java package names would be renamed to org.apache.uddi. All Java source files will contain headers based on the ones found in the Apache SOAP package (essentially the Apache license) The cvs repository, mailing list, and the web site will be hosted on apache.org Comments, questions, concerns? - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache's Java XML projects' portability into non-ASCII environments
Hey there. Been to Prague during the past week, took some fresh air there... What a beautiful city. --- It appears that Apache's Java-based XML projects use some configuration files in order to operate. Those files are being read by a Reader object (such as java.io.BufferedReader, java.io.InputStreamReader). Such files are being read by constructing a reader on the input stream, defaulting to the platform-default encoding. For example, in the Xalan-J project, class org.apache.xalan.serialize.CharInfo, when we read XMLEntities.res or HTMLEntities.res, a BufferedReader is constructed on an InputStreamReader, which is constructed on an inputstream, without mentioning the encoding in which the file resides - thus assuming default platform-encoding. This works pretty well on ASCII environments, since those text files really reside as ASCII text files, so the default platform-encoding is enough. However, a problem arises when trying to use Xalan-J on a non-ASCII environment, such as IBM's OS/390 which uses EBCDIC. The product simply doesn't work. I already opened a new bug report about the specific problem in org.apache.xalan.serialize.CharInfo (see the link to bug #4000 in the bottom), and I believe it should be fixed, but it might not be enough. Xalan-J was an example. If I recall right, Xerces-J has this problem too. It's obvious that if we want to make Apache's Java-based XML projects as portable as possible, then every place in which a text file, which is NOT encoding-standardized (such as Manifest files, which must be UTF-8 for example) is being read - should NOT make any assumption on the default platform encoding. If Xalan is being built in an ASCII environment, and its configuration files are in ASCII, then ASCII should explicitly be mentioned when reading the configuration file. I'm not talking about the actual way of doing this (hard-coding into the source, or reading some properties from the manifest-files, which are standardized to UTF-8 so no problem here), I'm just rising the problem. I think we should state our position in this subject. We can go and fix whenever needed; we can also just state that these are the changes that must be made in order for this product to run on a non-ASCII environment etc; anyway, some action is needed. My opinion is that the code should be as portable as possible, with no modifications needed to be performed by the user (such as converting ASCII to EBCDIC). Any comments, please? - Isaac P.S. here's the link to the original problem reported by me using BugZilla - http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4000 - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Services API?
Isaac Shabtay wrote: Hey again. JAXP has javax.xml.parsers.DocumentBuilderFactory and javax.xml.transform.TransformerFactory, which are used to create a factory implementation. Both have some sequence of searching to the factory implementation name. One of the steps is quoted below (from javax.xml.parsers.DocumentBuilderFactory's javadoc): START QUOTE= Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.DocumentBuilderFactory in jars available to the runtime. Platform default DocumentBuilderFactory instance. END QUOTE= My question is- what is this services API? I've been looking in the JAR file specification, and all I could see there is just a short explanation about this mechanism. There was no API there. They gave an example there, which uses a class named Service and a method called providers, but I couldn't find this Service class anywhere. Looks like the javadoc is wrong. There is no services API being used, but rather the service provider location mechanism that is documented in the jar specification is implemented directly in the code. The problem is, that currently, Apache's version of javax.xml.parsers.DocumentBuilderFactory (as well as javax.xml.transform.TransformerFactory) uses the hard way in order to get this data (constructing an input stream, a reader etc. to read the file, then read the line in that file etc.). Anyway, logically, if the service provider issue is so standardized, it's obvious that some programmatic API should be supplied. This way, we can avoid bugs like #2291 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2291). Any comments? Did I miss anything? I agree, all code that uses the service provider location mechanism should share common code. There is a Service class that implements the service provider location mechanism that is outlined in the JAR spec, however, that class is part of JDK 1.4. Since JAXP also has to run unbundled from JDK 1.4, it has to have its own implementation. In any case, I have already fixed the bug you referenced in the xml-commons module. The problem is that other projects like xalan and xerces have not been updated to use the fixed version of the code. (Actually, I think Shane said he updated Xalan.) However, I think the real fix will be to copy the code from xml-commons as part of the build so that someone does not have to manually update a copy for each release. I implemented such a system for crimson, but it has yet to be done for the other projects that use the JAXP API. The same principle applies to other APIs such as SAX and DOM. (There may be additional complexities involved, though.) Several weeks ago I posted messages on this topic to xerces-j-dev and general@xml. I also said I would provide a patch for the xerces build, but I haven't yet finished that task. When I fixed the bug, I thought I had closed it, but maybe someone else opened another bug report. Not sure whether I should close #2291 or not. -Edwin - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] UDDI4J on Apache?
+1 from me. Sounds like a great addition to the Apache XML project! Sam Ruby [EMAIL PROTECTED] on 10/10/2001 10:00:52 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Donald Leslie/CAM/Lotus) Subject: [POLL] UDDI4J on Apache? Background: UDDI4J is an existing Open Source project, hosted on IBM DeveloperWorks and under the IBM Public License. Details, including source code, can be found at http://oss.software.ibm.com/developerworks/projects/uddi4j. More information on the specification which this code implements can be found at http://www.uddi.org/. Another company has approached IBM and expressed an interest in contributing, but expressed reservations based on where it was hosted, and requested that we consider transferring it to a neutral location. As this code complements and works closely with Apache SOAP and Axis, Apache seemed like a natural fit. This other company readily agreed. Approximately six active developers are associated with this project at this time. We expect this number would increase should it be accepted as an Apache XML subproject. General Approach: Java package names would be renamed to org.apache.uddi. All Java source files will contain headers based on the ones found in the Apache SOAP package (essentially the Apache license) The cvs repository, mailing list, and the web site will be hosted on apache.org Comments, questions, concerns? - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: Software company falsely blames SUN for forcing them closed source?
I recently sent the following e-mail to a large number of people within SUN (and a couple of people outside SUN). While people who have been following goings on at Enhydra.org may view this as rather old news, I think it is important. The question is are the licensing conditions attached to J2EE technologies incompatible with Open Source development? A company called Lutris claims they are, if this is really true it has very important implications for JBoss, Tomcat and similar projects. While most of us are not in a position to definitively confirm or refute Lutris's claim I felt SUN would have the legal muscle and the motivation to do so - hence my e-mail to them. However not one person from SUN responded so I'm forwarding it to a number of groups in the hope of encouraging a clear and definitive answer to the question. Until we have such an answer I feel the confusion caused in the community will be harmful to the development and acceptance of Open Source products such as JBoss and Tomcat. [ Please also look at http://instantdb.tripod.com/ Sincere apologies to people who are receiving this e-mail for a second time - I promise I won't disturb you again. ] [ The original e-mail follows ]- [ Note: some non-SUN people have been CCed a copy of this. ] Dear SUN (and SUN employees), I know that there are many open source project based around SUN technologies and that SUN actively backs many of them. Two of my favorites are JBoss, a J2EE implementation, and Tomcat, the SUN reference implementation for JSP and Servlets. Both these developments have been great successes and SUN's licensing conditions for the relevant technologies do not seem to have hampered the development of either. Despite this a company called Lutris has recently claimed that it has been forced to close source all future development of its previously open source Enterprise Enhydra J2EE application server due to its failure to negotiate a license agreement with SUN. See this page: http://enterprise.enhydra.org/ While Lutris uses wording that's deliberately ambiguous and so hard to pin down they're definitely placing the blame squarely at SUN's door. This can be clearly seen in this article where NewsForge quote Keith Bigelow, Lutris Vice President of Marketing, practically verbatim: http://www.newsforge.com/article.pl?sid=01/09/13/2036205mode=thread Obviously Lutris's claims have worried those using other Open Source projects based on SUN technologies. JBoss have issued reassurances, saying Lutris' decision to close its source seems clearly driven by its own business considerations and not by Sun., see this page: http://www.jboss.org/licensesun.jsp The confusion and worry created by Lutris is clearly bad for SUN and bad for the Open Source community (that SUN has supported so much). While individuals like myself have had little luck trying to push Lutris on these issues I think SUN is in a position to demand that Lutris retracts any false statements and clarifies areas where they have deliberately tried to cause confusion. Yours, George C. Hawkins PS Lutris have done similar things in the past to what they are now doing with Enhydra Enterprise, coming up at the time with different reasons to the current it's all SUN's fault excuse - so making their current claims even less credible. See this page for a fuller discussion of this and previous events: http://instantdb.tripod.com/ PPS I addressed this letter to SUN, clearly SUN is many people, engineers, PR people, VPs etc. While only some can respond definitively on SUN's behalf to a letter such as this (just the lawyers I suspect), I think it's relevant to all. Please forward to anyone you think should see it who isn't in the original CC list - thanks. My apologies to any who think they were not an appropriate recipient for this e-mail. - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Services API?
Hey again. JAXP has javax.xml.parsers.DocumentBuilderFactory and javax.xml.transform.TransformerFactory, which are used to create a factory implementation. Both have some sequence of searching to the factory implementation name. One of the steps is quoted below (from javax.xml.parsers.DocumentBuilderFactory's javadoc): START QUOTE= Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.DocumentBuilderFactory in jars available to the runtime. Platform default DocumentBuilderFactory instance. END QUOTE= My question is- what is this services API? I've been looking in the JAR file specification, and all I could see there is just a short explanation about this mechanism. There was no API there. They gave an example there, which uses a class named Service and a method called providers, but I couldn't find this Service class anywhere. The problem is, that currently, Apache's version of javax.xml.parsers.DocumentBuilderFactory (as well as javax.xml.transform.TransformerFactory) uses the hard way in order to get this data (constructing an input stream, a reader etc. to read the file, then read the line in that file etc.). Anyway, logically, if the service provider issue is so standardized, it's obvious that some programmatic API should be supplied. This way, we can avoid bugs like #2291 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2291). Any comments? Did I miss anything? - Isaac - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
