Home >> All

•	soapical.likeoldsax.* (14)	•	soapical.soapmeter.* (67)	•	soapical.soapmill.* (157)
•	soapical.soapmillsamples.* (10)	•	soapical.util.* (25)

• soap: Javadoc index of package soap.


Package Samples:

• soapical.soapmill.xml.monitor: your interface to Soapmill: implement SoapmillAgent  
• soapical.likeoldsax
• soapical.util
• soapical.soapmeter.events
• soapical.soapmeter.gui
• soapical.soapmeter.tcp
• soapical.soapmeter
• soapical.soapmill.monitor.events
• soapical.soapmill.monitor.gui
• soapical.soapmill.monitor.xml.config
• soapical.soapmill.monitor
• soapical.soapmillsamples.echo
• soapical.soapmillsamples.three_agents
• soapical.soapmill.agents
• soapical.soapmill.engine
• soapical.soapmill.lush
• soapical.soapmill.throwable
• soapical.soapmill.xml.controller
• soapical.soapmill

Classes:

• SpecificXMLWriter: Convenience class for generating XML. This class provides easy, SAX1-style functions for your convenience when you are generating XML in mostly one namespace: startElement just pass in a local name and optionally an Attributes endElement just pass in a local name emptyElement equivilant to calling startElement then endElement addAttributes adds unprefixed attributes The best way to use this class is to extend it and create a simpler version of the constructor. For example: public class ExampleWriter extends SpecificXMLWriter { public ExampleWriter(Writer writer) { super(writer, EXAMPLE_NAMESPACE, ...
• SAXToSOAPElement: A SAX2 ContentHandler which converts the input tree into a SOAPElement. Easy way: // Reader yourStuff; // SOAPEnvelope yourEnvelope; // if you just want a regular SOAPElement: SOAPElement se = Soapkit.toSOAPElement( yourStuff ); // if you want to create a SOAPBodyElement: SOAPBody soapBody = yourEnvelope.getBody(); SOAPBodyElement sbe = Soapkit.toSOAPBodyElement( soapBody, yourStuff ); // if you want to create a SOAPHeaderElement: SOAPHeader soapHeader = yourEnvelope.getHeader(); SOAPHeaderElement she = Soapkit.toSOAPHeaderElement( soapHeader, yourStuff ); Not-so-easy way: use this like a regular ...
• LockedAction: The basic idea is that we want some sort of action that quietly disables itself if there are currently other actions like it running -- this prevents all sorts of nasty conflicts from happening. To make this slightly sweeter, we can group mutually exclusive actions together by constructing them with the same lock. LockedActions only prevent other LockActions with the same lock from running Any useful LockAction would implement process() as the main body of the action. This should look vaguely familiar to the AbstractAction in the Cocquet XML editor :-) (thanks for the lessons, Christophe)
• BlinkyBpPanel: A visualisation to show what modules are currently active in the system. We'll use Norbert's very simple idea that we consider an agent active between the times that it receives and sends a message. When an agent is active, we highlight it. FIXME: BlinkyPanel needs to force a resize if the elements don't fit on the screen. TODO: GO LEARN ABOUT JGRAPH! (google it) Let the user drag nodes of this visualiser around. Draw lines between nodes whenever there is a connection. TODO: Add timestamp checking on the messages, if the message is older, than certain info we do not update
• SpecificContentHandler: A wrapper to make ContentHandler easier to work with when you already know most of the content will be in a specific namespace. All events are passed to the wrapped ContentHandler This class provides SAX1 style functions to use when you already know what namespace you want your XML to be in. It is most useful for when you are trying to create XML by using SAX in reverse, for example, by using Megginson's XMLWriter. The best way to use this class is to extend it and create a simpler version of the constructor.
• ConnectionEventCannon: A ConnectionEventCannon fires ConnectionEvents (of course). This way we don't need to subclass or reimplement the bit that fires events or keeps track of listeners. Note: you might think that you could simply make the addListener and fire* methods of ConnectionEvent static, but then you lose any ability to make distinctions between various different SOURCES of ConnectionEvent and their listeners. One example is we are monitoring more than one port at the same time.
• FileSender: Agent for sending fake data. The idea is two have a base directory containing subdirectories. Each of these subdirectories is mapped to a message content type (like "semantic representation"), either implicitly through its name, or explicitly through a hard-coded table. You choose a subdirectory and one of the files in that directory through your favourite user interface. When you instruct the FileSender to send that file, it will figure out the rest (message content type, etc).
• OutputPartsTest: Junit test to test out output message parts. The WSDL output message can define multiple parts, but the response recieved from the remote service may not match what is defined in the WSDL. Its been decided that parts defined in the WSDL but not received should be set in the output WSIFMessage with a null value, and that parts in the response but not in the WSDL should be added to the ouput WSIFMessage.
• InputPartsTest: Junit test to test out input message parts using the AddressBook sample. The WSDL input message can define multiple parts, but the parts in the WSIFMessage passed to the WSIFOperation may not match what the WSDL defines. Its been decided the parts defined in the WSDL but not in the WSIFMessage should be sent as null, and parts in the WSIFMessage but not in the WSDL should be ignored.
• FakeServer: A socket "server" whose sole job is to respond with a prerecorded response to the first request it gets (and then stop). You start the server by starting the thread this function returns. The server sets _fakeServerException if it catches something; what your unit test could do is sit through a delay. If you _fakeServerException is set after the delay, then we throw an exception
• CallInvokingThread: Makes a call over a SOAP Connection. The reason this Thread is neccesary is that Axis doesn't provide a proper implementation of JAXM with a one-way messages (or that i am making a mistake in assuming the one-way nature of JAXM messages) That's all... the reason this doesn't do anything is because Soapmill communications are one way; we just invoke it and return immediately...
• Soapkit: The Soapkit provides the converters to and from SOAPElement. to from toSOAPElement toSOAPHeaderElement toSOAPBodyElement Reader, InputSource DOM Node toString SOAPElement, DOM Node
• SoapmillMessageContentException: Thrown if the contents of this SoapmillMessage could not be parsed correctly. This is strictly so that people calling SoapmillMessage toSOAPMessage can tell if it failed because the message content was bad (i.e. the user's fault and this exception gets thrown) or for something more serious. This seems like a bad idea, but i don't know how to get out of it.
• XMLNodeUserObject: A wrapper for the Element class who's toString function displays the Element's label. This wrap serves a second function of intergrating all inherited namespace information into the node This is meant to be used in a quick'n'dirty XML-viewing JTree FIXME: this entire class is just a temporary hack i should probably be implementing TreeModel or something
• ThreeAgentsHandler: A simple SAX ContentHandler for the XML data handled ThreeAgents . Note, this is very poorly implemented, and anybody who writes code like this for his service deserves to be slapped upside the head. Note: normally, you wouldn't write a class like this... you'd take advantage, for example, of Dirk's fancy MMIL parser
• PrettyXML: Prints XML as in some HTML form, for example, with syntactic highlighting and indentation. This printing is controlled by an XSLT sytlesheet. If the XML is not well-formed, or the stylesheet is missing/broken, it is printed in raw form with an error message. Note: for this to work, you have to set the system property
• JXMLTreePanel: JXMLTreePanel displays some XML as a standard JTree (the kind you get when dealing with file hierachies, like with Windows Explorer or Mac Finder) TODO: I would eventually like to replace this with a special TextField that highlights the entire XML node when you click on a part.
• MapToMany: An object that maps keys to values. A MapToMany cannot contain duplicate keys; BUT unlike Maps, each key can map to any number of values. FIXME: if i really gave a damn, i would make this an interface, and create an abstract class called "MapToCollection" which implements this interface
• NullAgent: A minimal implementation of SoapmillAgent. Used for unit testing... probably doesn't do anything interesting. Look in the samples if what you had in mind was to find out how to use the SoapMMIL FIXME: why is it, when running the unit tests from a gui, the _msgRecognisedCount is impossible to reset?
• ControlAgent: A SoapmillAgent that receives messages for controlling the Soapmill itself. This is started by default. If you do not want ControlAgent to be started by default, you should contact the person maintaining Soapmill's code. See etc/schema/soapmill_control.xsd
• RelevantStackTraceWriter: A Writer for printing only the interesting bit of a stack trace. You pass it the name of a class and function. When it detects that the stack trace has gone past that class/function, it stops writing. Otherwise, it passes the stuff off to its embedded Writer.
• DocumentHandlerWrapper: A SAX2 ContentHandler which passes its events directly to a SAX1 DocumentHandler. The difference between this and XMLReaderAdaptor approach is that we try to keep track of the namespaces, and hand -insert the namespace attributes when it needs to
• Standalone: Soapmill starter for standalone mode only . This is if you want to launch Soapmill without the ability to receive SOAP messages from the outside world. It's useful when you know absolutely that your applications fits on a single machine.
• SoapmeterGuiConstants: TODO: when Java 1.5 comes out we can use the import constant capability to provide both convenience and localisation (because this will no longer have to be an interface, we can set the values of the "constants" via a i8ln table lookup)
• TcpConfigPanel: Graphical display for the TCP transport configuration. It tells, for example, which local port the Soapmeter is forwarding to which remote server/port. This is used by both TcpmonPage and SoapmeterPage .

Home | Contact Us | Privacy Policy | Terms of Service