Menu
▾
▴
xbeans-interest — This list is for discussion of functionality, usability and project direction.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(13) |
Feb
(13) |
Mar
|
Apr
(4) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tr0n <tr...@gm...> - 2005-05-25 15:28:54
|
Hi,
I'm trying out the HTTP receiverBean and I'm having some trouble. I've
setup Apache v1.3.33, Perl v5.8.6 and CGI on WinXP. My CGI script
under Windows looks as follows:
#!java -classpath .;xbeansCompac.jar;xbeans.jar;xerces.jar
receivertest.ReceiverDemo
This properly runs the java and displays the output (I've also tried
with a simple HelloWorld.class and it worked ok).
When I send an XML document from the sender side (senderBean) to my
.cgi URL address (http://localhost/cgi-bin/receiver.cgi) I get the
following error message:
--------------
<html>
<head><title>http</title></head>
<body>
<p>Exception in http ReceiverBean: Error processing at component
parser: error parsing document org.xml.sax.SAXParseException: An
invalid XML character (Unicode: 0x1f) was found in the prolog of the
document..
Error processing at component parser: error parsing document
org.xml.sax.SAXParseException: An invalid XML character (Unicode:
0x1f) was found in the prolog of the document..
at org.xbeans.parser.ParserBean.generateDocument(ParserBean.java:12=
5)
at org.xbeans.communication.Representation.internalizeAndContinue(R=
epresentation.java:90)
at org.xbeans.communication.http.receiver.ReceiverBean.receive(Rece=
iverBean.java:107)
at receivertest.ReceiverDemo.jbInit(ReceiverDemo.java:50)
at receivertest.ReceiverDemo.<init>(ReceiverDemo.java:33)
at receivertest.ReceiverDemo.main(ReceiverDemo.java:42)
</body></html>
--------------
Any idea what the problem might be? This is how the XML document looks like=
.
<?xml version=3D"1.0"?>
<person>
<fname>John</fname>
<lname>Smith</lname>
<phone type=3D"work">563-456-7890</phone>
<phone type=3D"home">534-567-8901</phone> =20
<email type=3D"home">js...@so...</email>
<email type=3D"work">jo...@lo...</email>
<address type=3D"home">34 S. Colon St.</address>
<address type=3D"work">9967 W. Shrimp Ave.</address>
</person>
I've also tried with other XML documents, but the error message was the sam=
e.
Regards,
Tadej
|
|
From: john d b. <jba...@cs...> - 2003-07-30 17:20:35
|
Okay, I think I got it. You would first use the translator bean and then the synchronizer. Never mind my question then. Thanks. |
|
From: john d b. <jba...@cs...> - 2003-07-30 17:03:51
|
Hi, Is anyone else looking at this list? I've been going through the white paper at xbeans.org and found a description of all the different types of Xbeans. This looks great! But I would like an updated description of the Synchronizer Xbean. Specifically, how would you specify what gets merged in the output doc? Thanks. |
|
From: Bruce M. <ma...@xb...> - 2003-07-10 04:24:39
|
Shobha, Are you talking about the ViewerBean? It currently does not have the functionality of returning a selected node? You would need to add that. But it is not too difficult to do so. It's a bit of Swing programming using the JTree that is embedded in the ViewerBean. If you make this enhancement to the ViewerBean, we would appreciate it if you would send the changes so that we could include it in the next release of Xbeans. Bruce Shobha Rani Jagathpal wrote: > Hi, > I have used Xbeans to view the selected file in tree form. How do I get > the exact element or its value which is selected. If I getPath (), 2 or > more elements with same name and value cannot be distinguished. > > Thanks > Shobha > |
|
From: George M. <geo...@ya...> - 2002-11-27 16:07:35
|
Hi, In the TranslatorViewer class supplied, there is a need for a previewer and a postviewer. So we have parser->previewer->translator->postviewer. How come the DOM from the parser is not sent directly to the translator,i.e., parser->translator->viewer? Thanks, George |
|
From: Bruce M. <ma...@xb...> - 2002-10-22 23:59:02
|
The Xbeans Communication Pack is now available for download at xbeans.org. The final open-source release of Xbeans 2 is also available. The Xbeans Communication Pack greatly expands the set of senders and receivers included with Xbeans. The Communication Pack provides senders and receivers for HTTP, Servlets, RMI, CORBA, EJB and SOAP/Web Services. Using the sender and receiver you can easily send XML "over the wire". The sender-receivers support GZIP compression, simply by setting a property on the sender. A generic sender-receiver is also included. The generic sender-receiver makes the communication/distribution mechanism completely transparent to the rest of your code. Your code establishes the protocol dynamically by setting a simple protocol property and the generic sender-receiver loads the appropriate Xbean. Thanks to Dion Almaer of The Middleware Company and Mark Shocklee of Product Data Integration Technologies. Both Dion and Mark contributed code to the Xbeans Communication Pack. |
|
From: Mailer M. <mai...@ya...> - 2002-07-31 10:21:54
|
Hello All, My requirement is to generate XSL source code given the schema of source and target XML. Does anyone has this kinda source code??? XSL-WIZ does this type of job, but I need to do it myself as some customization will be required. Can anyone help in this regard. Thanks in advance Dennis __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
|
From: meiyaps <me...@in...> - 2002-06-27 04:45:41
|
-- ------------------------------------------------------- S.Meiyappan AdventNet Development Center India (P) Ltd., SREE NARAYANA COMPLEX No.11 Sarathy Nagar ,Velachery Chennai - 600 042 (Near Vijaya Nagar Bus Terminus) Ph: +91-044-2431115, 2431215, 2435321-26 Ext : 392 Res : 2433779 http://www.adventnet.com "Friendship is a sweet responsibility never an opportunity" ------------------------------------------------------- |
|
From: Bruce M. <ma...@xb...> - 2002-06-26 14:13:45
|
Othman, Yes, your channel is possible. Simply use the parser Xbean, followed by the translator Xbean, followed by your own Xbean (your Java program), followed by the serializer Xbean. To create the channel, instantiate the Xbeans and hook them together by setting their DOMListener properties. Your Java code will need to implement both the DOMListener and the DOMSource interfaces. Don't worry, those interfaces are extremely simple! Yes, the project is still alive and well. We're currently working on an expanded set of communication Xbeans to support communication over SOAP and J2EE servlets and EJBs. Bruce Othman Haddad wrote: > hi everybody,i've got some questions:1) i want to use xbeans with java and xml transformations like for instance pipelining like this:xml->Schema validation->xslt->java program->xml ....is it possible? 2)is the project still available,because the last update was in december 2001 ?thank you very much for answers.. > ________________________________________________________________ > IncrediMail - La messagerie =E9lectronique a enfin =E9volu=E9 - Cli= quer > ici |
|
From: Nasseam E. <na...@ho...> - 2002-05-20 07:17:43
|
After I posted my comments about JDOM last week, I was asked to elaborate on the performance hit. Let me start off by giving a few differences and benefits of both DOM and JDOM. With DOM we have a standardized platform- and language-neutral interface for dynamically accessing and editing XML. If you noticed, the word "serializing" is not a part of the definition because the implementation was left out of the Level 2 spec. Therefore, DOM parsers provide implementation-specific classes and features for serializing which poses a problem to interoperability. However, the upcoming Level 3 spec, which is designed to extend and not replace Level 2, has an exciting list of new features. The most important feature being the Load and Save package which defines a standard way to build a DOM tree from various input sources and provides an API for serializing a DOM document out as XML. Traversing with DOM can require a great deal of attention and is also error-prone. DOM Level 3 will incorporate the ability to find nodes and traverse through a document using XPath, which will supply easier handling of XML documents. In addition, DOM Level 3 will add asynchronous loading with accompanying load and progress events, filtering load and save, and incremental/concurrent parsing. This will provide the ability to use a partial DOM document while it's still being parsed. I covered most of the spec that deals with enhancing performance but there are more features. Another important note one should mention is how JAXP uses DOM, SAX, and XSL to provide you with the ability to plug in any compliant parser or processor. So with the upcoming features and the already widespread use of DOM, why should you even think about using JDOM? JDOM is also building a loyal following and promises great features as well. It is currently in beta but is a JSR and will probably be included in the next version of JAXP. This simple fact should encourage a developer to glance at it. However, JDOM is so easy to use and its style fits into Java so well that your glance might lead you to stare a while. It is important to mention that JDOM is not a parser but rather uses SAX or DOM to build the JDOM document. Using SAX to build the representation is encouraged because of its speed and using DOM is encouraged for instances when you already have a DOM tree available. From the JDOM website: "JDOM documents can be built from XML files, DOM trees, SAX events, or any other source. JDOM documents can be converted to XML files, DOM trees, SAX events, or any other destination. This ability proves useful, for example, when integrating with a program that expects SAX events. JDOM can parse an XML file, let the programmer easily and efficiently manipulate the document, then fire SAX events to the second program directly - no conversion to a serialized format is necessary." JDOM is very robust and includes checking for well-formedness, XPath support using jaxen, XSLT support via TRaX, and will eventually have in-memory validation. It uses Java collections and behaves like Java. Still not convinced? Neither am I. DOM allows you to move between multiple implementations to suit your needs and also between different languages without having to learn an entirely new XML API. JAXP works on top of a DOM implementation and an XSL processor that you choose and promises future support for all DOM Level 3 additions. JDOM has proven to provide more features sooner, while still in beta, and has a lot of potential to expand and improve even more in terms of features and performance. It already has a standard way to serialize XML, jumping ahead of DOM in that regard. In early benchmarks, JDOM has performed poorly and, along with its lack of standardization, developers are hesitant to use it. However, most tests have been done with JDOM beta 7 and the current release beta 8 promises many speed optimizations and functionality improvements. Developers tend not to rely on promises but instead tend to rely on results from performance tests. In a world of various implementations, developers seek a solution with a balance of intuitiveness and performance. DOM wins for this balance and JDOM comes second for sheer intuitiveness. The JDOM gang needs to address the performance issue with some kind of results and not the following lame answer they give on their FAQ page when asked, "Are there any performance numbers?": "Not yet. JDOM is still really new! Only preliminary numbers have been taken, but they have been extremely promising. And JDOM hasn't been tuned yet!" Two years is not "really new" and why not post these "extremely promising" numbers for developers to see? I'll tell you why--JDOM didn't beat DOM on performance tests. This can be easily concluded from their posted excuse stating that "JDOM hasn't been tuned yet". Luckily, there have been some third-party performance tests conducted that compare various document object models. Two of which can be seen on IBM's and Sun's sites. Coincidentally, the articles on both sites work as a series in which they introduce various object models, show some benchmark results, and follow with some performance tips. Although some of the models have released newer versions since the publication of these articles, I still recommend you read them and familiarize yourself with the options you have. Here are the links: XML in Java: Document models, Part 1: Performance http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html XML in Java: Java document model usage http://www-106.ibm.com/developerworks/xml/library/x-injava2/index.html Java Technology and XML Part 1 -- An Introduction to APIs for XML Processing http://developer.java.sun.com/developer/technicalArticles/xml/JavaTechan dXML/ Java Technology and XML Part 2: API Benchmarks http://developer.java.sun.com/developer/technicalArticles/xml/JavaTechan dXML_part2/ Java Technology and XML Part 3: Performance Improvement Tips http://developer.java.sun.com/developer/technicalArticles/xml/JavaTechan dXML_part3/ The implementations tested scored differently on various tests so it is difficult to pick a clear winner. We won't really be able to conclude which implementation is best until JDOM 1.0 is released and DOM Level 3 support can be tested. Xerces has a partial implementation of DOM Level 3 which is considered experimental until DOM Level 3 moves from a Working Draft to a Recommendation. Surprisingly, the tests show that DOM and JDOM have a possible competitor in dom4j. But to save you a further headache, you should only consider JDOM and DOM because they are both part of (or will be part of) JAXP. With JDOM, most of the performance complaints have been related to the frequent creation of Iterators and Java objects. JDOM promises support for JAXP but will most likely be used instead of JAXP. You can consider JDOM and JAXP competing technologies in a way. They are both pluggable with a compliant parser of your choice. Regardless of which implementation you choose, JDOM is really nice if you are only working in Java and because it can read from existing SAX/DOM/XML sources, and can output to SAX/DOM/XML-receiving components. This ability enables JDOM to be a good choice as an intermediary to connect existing program components that are built against SAX, DOM, or XML. There are probably two other issues that one should consider when considering an implementation--XML data binding and results showing that (re)parsing the textual version of the XML document causes less overhead than the (de)serialization of DOM trees. However, many processors expect a DOM tree as input and therefore if you send a DOM tree it can work with it immediately--no conversion necessary. So even if you use JDOM you will have to output to DOM or XML because most processors do not have support for JDOM input. With JDOM, it is very easy to accept DOM input using the DOMBuilder class and easy to send DOM as output using the DOMOutputter class, but if you are working primarily in DOM and processors expect DOM then this rules out passing around JDOM documents. Although passing around a DOM tree requires more memory resources, this method is highly effective for post-processing such as using XSL for transformations. This is similar to the XBean approach as a DOM tree is fed to a translator bean. The fact that processors expect DOM trees and XBeans pass around DOM trees makes the current Xbeans model one of the most efficient ways to pass around data between components. If a developer wanted to use JDOM, then they would need to use the DOMBuilder class to create a JDOM Document, perform the necessary changes, then use the DOMOutputter class to send DOM back out to the next XBean in the channel. This would obviously be a performance hit caused by the conversion which depends on the size of the document both coming in and going out. Also, because there is no standard way to serialize a DOM tree and since JDOM uses a DOM parser to build its representation, this means JDOM depends on a DOM parser with implementation-specific serialization classes to output the DOM tree which means you MUST use the same DOM parser in the previous channel, to build the JDOM Document, and in the receiving channel--another reason to think again about using JDOM within an XBean. We are seeing a lot of inter-application passing around of DOM trees because developers can't wait to get the XML syntax out of the way. This is fine as long you have a model similar to the XBean model that uses the same implementation of DOM on both ends of the channel. Remember, there is currently no standard way to serialize DOM which might limit interoperability between different DOM parsers. The fact that passing around XML instead of DOM is faster is strange but expect that to change as DOM Level 3 promises to define a standard way to, not only serialize, but provide a way to filter serialization and a way to concurrently parse and use documents. The argument on whether DOM, JDOM, or XML is the fastest internal data representation for an application will not end until we see some more tests. Early tests and suggestions by various articles throughout the Web state that XML is the fastest and you also keep the advantage of an interoperable XML textual representation. Once you decide on a non-XML representation, your project no longer becomes loosely coupled. If you choose XML as the representation of choice, then you can use SAX, DOM, JDOM, dom4j, or any other implementation to work with the XML and, as long as you output XML, then you have no problems with component interoperability. One of the issues I mentioned that one should consider when choosing an object model is XML data binding. XML data binding is not a document object model but rather an alternative. As the name implies, XML data binding focuses more on the actual data contained within the XML document as opposed to the document itself. It would be nice if an XML-based application had a standard way to work with XML as Java objects. This is exactly what you get with XML data binding--a schema compiler and a runtime framework to support mapping between XML documents and Java objects and vice versa. The schema compiler will have future support for XML Schema but currently it translates XML DTDs into one or more Java classes without requiring the developer to write complex parsing code. The generated code performs error and validity checking of incoming and outgoing XML documents which ensures that only valid messages are handled. There a lot of advantages to data binding according to your Java and XML scenario. The Java Architecture for XML Binding (JAXB) will provide a standard interface but in the meantime, Castor is a popular mapping framework between Java objects, XML documents, SQL & OQL databases and LDAP directories, as well as Java Data Objects (JDO), a specification from Sun dealing with Java-to-RDBMS (relational database management system) persistence. There is also the Zeus framework from the nice folks at Enhydra. XML data binding is a whole other topic so here are some links to get you started if you are interested: XML in Java: Data Binding with Castor http://www-106.ibm.com/developerworks/xml/library/x-bindcastor/index.htm l Zeus - an open source Java-to-XML Data Binding tool http://zeus.enhydra.org Sun's Java Architecture for XML Binding (JAXB) http://java.sun.com/xml/jaxb/index.html In conclusion, when choosing to work with XML, the next step is to find the best fit for how to deal with the XML. Whether it's SAX, DOM, JDOM, or XML data binding, developers have to understand the pros and cons of each implementation as well as which method is optimal for a project's requirements. If you are overwhelmed with which implementation to choose, just pick JAXP and let it take care of everything for you. It is a Java specification, it attempts to plug the holes left by other implementations, and it is still evolving so you can expect it to meet all your demands. Here are a few more links that might be of interest: Processing XML with Java by Elliotte Rusty Harold http://www.ibiblio.org/xml/books/xmljava/ The author of the IBM articles on document object models and XML data binding provides the XML benchmark source so that you can run the tests yourself as well as other resources: Java XML Models Benchmark http://www.sosnoski.com/opensrc/xmlbench/index.html XML Stream (XMLS) - a format designed to eliminate most of the padding of XML text documents, allowing faster input and output of XML documents. http://www.sosnoski.com/opensrc/xmls/index.html Thanks for your patience, Nasseam na...@ho... |
|
From: Nicolas S. <Nic...@Di...> - 2002-05-13 22:40:53
|
Please, Don't answer directly to Nasseam since I need the response too... |
|
From: Nasseam E. <na...@ho...> - 2002-05-12 23:36:16
|
I am new to the list and noticed some threads regarding JDOM in the archives. You might have already finished the discussion and I'm pretty late but I have a few points to make about performance issues. JDOM relies on a SAX or DOM parser to build the JDOM representation. Most parsers use SAX to build a DOM tree so you are actually converting from SAX to DOM without even knowing it. You can create a JDOM Document using either SAX or DOM. From SAX to JDOM is a direct process. However, from DOM to JDOM is not as direct because you are using SAX to build the DOM tree and then to build the JDOM Document. Since all the Xbeans are using DOM interfaces, going from DOM to JDOM will cost you some performance. I just started reading about Xbeans so I don't know much but maybe you guys can clarify this for me. Maybe you should have a separate interface that only supports JDOM, uses SAX to build the representation, and excludes DOM entirely. Then you can throw in a JDOM to DOM and DOM to JDOM converter for interoperability between Xbeans that use different interfaces. I don't know if you want to go with all that trouble to make to separate interfaces but from what I have noticed, using event-driven APIs such as SAX is the most efficient way to build XML representations. Also, I would appreciate if anyone has any sample source for using JDOM with Xbeans. I noticed a few threads offering the source code for such projects. You can send it to na...@ho.... Thanks, Nasseam Elkarra |
|
From: Bruce M. <ma...@xb...> - 2002-05-07 11:06:13
|
I didn't understand what you want to do. So, no need to communicate the xml over the wire. Sorry. Your original email is as clear as can be. But I somehow read over the wire into it. To do what you want, simply do the following: Instantiate the ParserBean Instantiate the ViewerBean Set the DOMListener property of the ParserBean to the viewer Set the XMLSource property of the ParserBean to the XML file to be parsed. Invoke parser.generateDocument() I have attached some source code that does exactly that. I also included a small xml file and dtd with some data. Bruce P.S. This file was generated by JBuilder. I did not actually write it. But it is certainly fine to write the code that invokes Xbeans. It is not a requirement to use an IDE. Nicolas Silberzahn wrote: > Bonjour, > > Let's try with the simpliest: HTTP. > I don't totally understand the question since to read an XML file and to > print it to the console, i think i don't need any transport mechanism... > Merci beaucoup. > > Nicolas Silberzahn > > Digital Airways > Everywhere <Internet>Technologies</Internet> > www.DigitalAirways.com > > >-----Message d'origine----- > >De : Bruce Martin [mailto:ma...@xb...] > >Envoye : lundi 6 mai 2002 22:32 > >A : Nicolas Silberzahn > >Objet : Re: [xbeans-interest] Need for a jumpstart > > > > > >Nicolas, > > > >If you use an Java Bean design tool you don't write any code. The tool > >generates it for you. "Look Mom, no programming!" > > > >But if you want code, I can certainly send you some code. But the > >code depends > >on which version of the sender receiver you are using. That is > >why I ased you > >if you wanted to use the CORBA, the RMI or the HTTP version. > >Please let me know > >and I'd be happy to send you the code. > > > >Regards, > >Bruce > > > >Nicolas Silberzahn wrote: > > > >> That's precisely a bad idea. People don't need only a tutorial > >to start with > >> a new technology > >> > >> But code that's compile and work the first time they try it > >> There is no code in the tutorial. > >> > >> Just provide a main.java with a listener that reads XML, and > >another xbean > >> that print it on the console. I know how to go further then... > >> I mean code that compile and run. > >> > >> >-----Message d'origine----- > >> >De : Bruce Martin [mailto:ma...@xb...] > >> >Envoye : lundi 6 mai 2002 01:53 > >> >A : Nicolas Silberzahn > >> >Objet : Re: [xbeans-interest] Need for a jumpstart > >> > > >> > > >> >I see. Then I recommend following the tutorial that is on the web site. > >> >If you want to make it even simpler, you can skip the translator xbean. > >> >Just do parser->viewer->sender->receiver->viewer. The sender > >and receiver > >> >mentioned in the tutorial depend on the Java ORB included with modern > >> >JDKs. > >> > > >> >Bruce > >> > > >> >Nicolas Silberzahn wrote: > >> > > >> >> I still use nothing. I found some papers and wanted to build "the most > >> >> simple test" (the one i described) > >> >> I don't know there are many different implementation... > >> >> > >> >> >-----Message d'origine----- > >> >> >De : Bruce Martin [mailto:ma...@xb...] > >> >> >Envoye : samedi 4 mai 2002 17:42 > >> >> >A : Nicolas Silberzahn > >> >> >Objet : Re: [xbeans-interest] Need for a jumpstart > >> >> > > >> >> > > >> >> >Nicolas, > >> >> > > >> >> >Thanks for your interest in Xbeans. What implementation of > >> >> >sender-receiver are > >> >> >you using? The main.java will be impacted by that choice. > >> >> > > >> >> >Bruce > >> >> > > >> >> >Nicolas Silberzahn wrote: > >> >> > > >> >> >> I'm looking for a jumpstart program: a main.java with a listener > >> >> >that reads > >> >> >> XML, and another xbean that print it on the console. > >> >> >> I know how to go further then... > >> >> >> > >> >> >> For product acceptance, such a basic demo should be available > >> >> >for download > >> >> >> at the first page of the web site! > >> >> >> > >> >> >> _______________________________________________________________ > >> >> >> > >> >> >> Have big pipes? SourceForge.net is looking for download mirrors. > >> >> >We supply > >> >> >> the hardware. You get the recognition. Email Us: > >> >> >ban...@so... > >> >> >> _______________________________________________ > >> >> >> xbeans-interest mailing list > >> >> >> xbe...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/xbeans-interest > >> >> > > >> >> > > >> > > >> > > > > > |
|
From: Bruce M. <ma...@xb...> - 2002-05-04 15:50:02
|
Brian,
I have a couple of questions. Do you know which Xbean is generating the
exception? What are the XBean and XBean1 classes for in your example?
Bruce
Brian Wolf wrote:
> Hi, I get this error messge, although I seem to have set
> DOMListeners for all the listener type: org.xbeans.XbeansException:
> Error processing at component parser: next componen
> t not established.Thanks, Brian
> public class xbeantest {
>
>
> ViewerBean viewer = new ViewerBean();
> LoggerBean loggerBean = new LoggerBean();
> public xbeantest() { XBean xb = new XBean();
> xb.setXMLSource("c:\\b\\freqwords.xml");
> xb.setDOMListener(loggerBean);
> loggerBean.setLogFileName("xbeanlog");
> loggerBean.setDOMListener(viewerBean1);
> loggerBean.setDOMListener(viewer);
> loggerBean.setLogFileName("xbeanlog");
>
> try{
> xb.generateDocument(); }catch(Exception me){
> System.out.println(me);} }
> public static void main(String[] args) {
> xbeantest xbt = new xbeantest(); } } public class Xbean1
> extends ParserBean implements DOMListener, DOMSource {
> protected Document processedXmlDoc = null;
> protected DOMListener listener = null; public Xbean1(){
> } public void setDOMListener(DOMListener listener) {
> this.listener=listener;
> } public DOMListener getDOMListener() {
> return listener;
> } public void documentReady(DOMEvent evt) throws XbeansException {
> processedXmlDoc = processDocument(evt.getDocument());
> DOMEvent domEvt = new
> DOMEvent(this,(org.w3c.dom.Document)processedXmlDoc);
> fireDOMEvent(domEvt);
> } public void fireDOMEvent(DOMEvent domEvt) throws XbeansException {
>
> if(listener!=null){
> listener.documentReady(domEvt);
> }
> } public Document processDocument(Document doc) throws
> XbeansException {
> return doc;
> } public Document getDocument() throws XbeansException {
> return processedXmlDoc ;
> } }
|
|
From: Brian W. <br...@kn...> - 2002-05-03 19:23:55
|
=20
Hi,
I get this error messge, although I seem to have set DOMListeners for =
all the listener type:
org.xbeans.XbeansException: Error processing at component parser: next =
componen
t not established.
Thanks, Brian
public class xbeantest {
=20
=20
ViewerBean viewer =3D new ViewerBean();
LoggerBean loggerBean =3D new LoggerBean();
public xbeantest() {
XBean xb =3D new XBean();
xb.setXMLSource("c:\\b\\freqwords.xml");
xb.setDOMListener(loggerBean);
=20
loggerBean.setLogFileName("xbeanlog");
loggerBean.setDOMListener(viewerBean1);
loggerBean.setDOMListener(viewer);
loggerBean.setLogFileName("xbeanlog");
=20
try{
xb.generateDocument();
}catch(Exception me){
System.out.println(me);}
}
public static void main(String[] args) {
xbeantest xbt =3D new xbeantest();
}
}
public class Xbean1 extends ParserBean implements DOMListener, =
DOMSource {
protected Document processedXmlDoc =3D null;
protected DOMListener listener =3D null;
public Xbean1(){
}
public void setDOMListener(DOMListener listener) {
this.listener=3Dlistener;
}
public DOMListener getDOMListener() {
return listener;
}
public void documentReady(DOMEvent evt) throws XbeansException {
processedXmlDoc =3D processDocument(evt.getDocument());
DOMEvent domEvt =3D new =
DOMEvent(this,(org.w3c.dom.Document)processedXmlDoc);
fireDOMEvent(domEvt);
}
public void fireDOMEvent(DOMEvent domEvt) throws XbeansException {
if(listener!=3Dnull){
listener.documentReady(domEvt);
}
}
public Document processDocument(Document doc) throws XbeansException {
return doc;
}
public Document getDocument() throws XbeansException {
return processedXmlDoc ;
}
}
|
|
From: Nicolas S. <Nic...@Di...> - 2002-05-03 15:48:49
|
I'm looking for a jumpstart program: a main.java with a listener that reads XML, and another xbean that print it on the console. I know how to go further then... For product acceptance, such a basic demo should be available for download at the first page of the web site! |
|
From: Bruce M. <ma...@xb...> - 2002-04-23 14:54:47
|
Xbeans defines two interfaces DOMSource and DOMListener. An Xbean that supports the DOMListener interface can receive a DOM -- so you would use that interface. To receive a DOM from an Xbean, you implement the DOMListener interface and use the DOMSource interface to register yourself as a listener. The white paper at www.xbeans.org explains this in more detail. Bruce Brian Wolf wrote: > hi,I would just like to know if I have a DOM built, how to input it > into an Xbean,and how to access a DOM from an xbean.Thanks, Brian |
|
From: Brian W. <br...@kn...> - 2002-04-23 13:12:32
|
hi, I would just like to know if I have a DOM built, how to input it into an = Xbean, and how to access a DOM from an xbean. Thanks, Brian=20 |
|
From: Bruce M. <ma...@xb...> - 2002-04-04 01:40:08
|
The translator xbean is simply wrapping an xslt engine at runtime. If you are
using the dependent jars distributed with xbeans, then it is xalan version 2.2.
Perhaps the undesirable behavior you are experiencing is a "feature" of that
version of xalan. I do not know.
At runtime, the translator bean simply calls:
Transformer transformer = tFactory.newTransformer(
new StreamSource(tf));
transformer.transform(
new javax.xml.transform.dom.DOMSource(sourceDocument),
domResult);
You might try using a different xalan version or a different xslt engine. Any
xslt engine that supports the javax.xml.transform.* interface (TRAX) should
work.
We would appreciate knowing if you find something about the usage of the xslt
engine by the translator bean that is causing the problem. If you find
something, we'll change the invocation code appropriately for the next release.
Thanks,
Bruce
Bill Kaufman wrote:
> When I use the TranslatorBean to apply my xsl stylesheet the
> expected empty html tags are not generated (say <hr> instead of <hr/>) even
> though <xsl:output method="html" /> was specified. (I need this so I can
> display html in a JEditorPane, which supports only html3.2 - it doesn't like
> the slash).
>
> Also it seems I cannot suppress the <?xml...?> header in the usual
> way.
>
> Help will be very much appreciated.
> TIA,
>
> Bill
>
> _______________________________________________
> xbeans-interest mailing list
> xbe...@li...
> https://lists.sourceforge.net/lists/listinfo/xbeans-interest
|
|
From: Bill K. <BKa...@sk...> - 2002-04-02 05:46:22
|
When I use the TranslatorBean to apply my xsl stylesheet the expected empty html tags are not generated (say <hr> instead of <hr/>) even though <xsl:output method="html" /> was specified. (I need this so I can display html in a JEditorPane, which supports only html3.2 - it doesn't like the slash). Also it seems I cannot suppress the <?xml...?> header in the usual way. Help will be very much appreciated. TIA, Bill |
|
From: Bruce M. <ma...@xb...> - 2002-02-16 20:52:12
|
The beta shipped with Xerces 1.4.3 and Xalan 2.2. D14. The idea is to keep a list of qualified versions of underlying software in http://www.xbeans.org/compat.html Bruce Chris Cuilla wrote: > What versions of Xerces and Xalan are presently being packaged with Xbeans? > > Chris > > _______________________________________________ > xbeans-interest mailing list > xbe...@li... > https://lists.sourceforge.net/lists/listinfo/xbeans-interest |
|
From: Bruce M. <ma...@xb...> - 2002-02-16 20:51:41
|
Chris,
Using JDOM and log4j are fine. The only issue about using JDOM is one o=
f
performance. There was a previous email exchange between several of us a=
bout
the performance of converting between DOM Documents and JDOM. This is re=
levant
since Xbeans that use JDOM would need to do this.
Everybody thought it wasn=B4t an expensive thing to do but nobody knew fo=
r sure.
Do you have any experience with this?
Bruce
Chris Cuilla wrote:
> I am wondering if it would be cool to add Apache's log4j (Apache licens=
e)
> and JDOM ("Apache-style open source license") to the Xbean distribution=
as
> well, since both of these would be very useful for the following reason=
s:
>
> 1. Many Java open source projects seem to be using log4j (JBoss, Jakart=
a
> projects, etc.) and it would be nice to follow along on this emerging
> "defacto standard". More specifically, it would be nice to build Xbeans
> that log things in a consistent fashion. Log4j would be the choice in t=
hat
> case.
>
> 2. JDOM is MUCH easier to deal with than the org.w3c.dom API. I find my=
self
> converting to JDOM to do many things and then converting back. Furtherm=
ore,
> some of the Xbeans I'd like to contribute would be better if I could =
rely
> on JDOM as a standard part of the Xbeans distribution.
>
> Thoughts?
>
> Chris
>
> _______________________________________________
> xbeans-interest mailing list
> xbe...@li...
> https://lists.sourceforge.net/lists/listinfo/xbeans-interest
|
|
From: Bruce M. <ma...@xb...> - 2002-02-16 20:51:32
|
Chris, The CORBA dependency is on the JavaIDL classes shipped with the standard 1.3 JDK. There is no need for a commercial ORB. Bruce Chris Cuilla wrote: > I have begun an attempt to compile the Xbeans framework. > > It appears that minimally, there is a dependency on some CORBA stuff. Where > would I find these classes to compile against? > > Secondly, there are some other problems compiling. I want to be sure that > I am aware of any outside dependencies before I go too far here. Are there > any? > > Chris > > _______________________________________________ > xbeans-interest mailing list > xbe...@li... > https://lists.sourceforge.net/lists/listinfo/xbeans-interest |
|
From: Chris C. <ch...@cu...> - 2002-02-14 21:31:48
|
I have begun an attempt to compile the Xbeans framework. It appears that minimally, there is a dependency on some CORBA stuff. Where would I find these classes to compile against? Secondly, there are some other problems compiling. I want to be sure that I am aware of any outside dependencies before I go too far here. Are there any? Chris |
|
From: Chris C. <ch...@cu...> - 2002-02-14 18:24:19
|
I have discovered what appears (to me) to be a problem with the Translator. More precisely, it appears to be a problem with the DOMResult object. If the XSLT style sheet I use is setup to output a DOCTYPE declaration, this apparently is not picked up in the DOMResult. Using the StreamResult, the DOCTYPE declaration seems to come through just fine. Perhaps I am missing something. Perhaps this is a bug in DOMResult. Not sure yet. Chris |
8 messages has been excluded from this view by a project administrator.
