Junaid Bhatra

For java source compiled with the debug option (-g), the class files contain the method paramter names. However these are not available via Reflection. Does anyone know of a way to get these? Does JavaAssist or BCEL provide such a facility? I had a quick look at JavaAssist API and could not find a way.

I need the paramter names for a custom WSDL creation from Java Source files for Web Services development. I would like the WSDL parameters to be something meaningful rather than generic param1, param2, etc. I know that Web Service engines like Axis do the exact same thing, probably via class file parsing, which I would hate to do on my own.

You can think of the Home interface as really being a factory for creating/locating your actual EJBObjects. In general it's a good design to separate your business object interface (Remote interface) from the
interface that manages the location/life-cycle of your business objects. You should not mingle up the two.

Here's an example:
<message name="processDocRequest"> <part name="input" element="tns:MAXWORKORDER"/> </message> <message name="processDocResponse"> <part name="result" element="tns:MAXWORKORDER"/> </message> <portType name="WSTest"> <operation name="processDoc"> <input message="tns :-P rocessDocRequest"/> <output message="tns :-P rocessDocResponse"/> </operation> </portType>
Here tns:MAXWORKORDER refers to a concrete element in your schema definition within the <types> section of your WSDL.

We had the exact same requirement and here's the apporach we took:
Publish our services in AXIS via the "message-style" service that AXIS offers.
Basically you hand-write the WSDL, which contains the schema definitions of the message parts, and you publish this as a document/literal type of webservice.
Within AXIS, you specify the style of the webservice as "message", and point it to your custom WSDL:
<service name="WSTestService" provider="java:MSG" style="message"> <wsdlFile>/WSTestDocStyle.wsdl</wsdlFile> <parameter name="allowedMethods" value="processDoc"/> <parameter name="wsdlPortType" value="WSTest"/> <parameter name="scope" value="Request"/> <parameter name="className" value="jbhatra.WSTest"/> <parameter name="wsdlServicePort" value="WSTest"/> <parameter name="wsdlTargetNamespace" value="www.mro.com/mea"/> <parameter name="wsdlServiceElement" value="WSTestService"/> </service>
The method signature looks like:
public Document processDoc(Document input)
Here the entire contents of the <SOAP-BODY> is handed to your method as a DOM Document object.
AXIS allows 4 method signatures for message-style service(read the document for that).
Using this approach we accomplish the following things:
1) Pass around XML messages within SOAP without the overhead of XML/Java Object data-binding.
2) Indicate to the end-user the schema of the input and output XML messages that you expect.
Note that for message-style webservices, AXIS hands you the entire SOAP-Body, it does not convert them to Java objects, neither does it do any schema validation (it's up to you to do that)
Hope that helps.

Normalizing an XML document means removing whitespace characters (spaces, tabs, linefeeds, etc) from the XML document so that you can directly work with the element & attribute values. It's useful when you wish to compare 2 XML documents.
Canonicalizing an XML document is a much stricter process, which involves among other things, replacing character & parsed entity references with their values, and replacing CDATA sections with their character content.

I've read that JAXM won't be part of J2EE 1.4. Where does this leave this API, considering that many SOAP implementations (including AXIS) do not currently implement it. Is JAX-RPC, SAAJ all that is required for a SOAP implementation to be J2EE 1.4 compliant?

You could try using:
String jreVersion = System.getProperty("java.vm.version"); if(jreVersion.startsWith("1.4")) //do something else //do something else
However be careful when you use classes from 1.4 & the target JRE is not 1.4. The problem is that some JRE's may implement eager loading of classes, i.e when your class is loaded, the JVM might try to resolve all symbolic references and load those classes as well up front. So you may end up getting ClassDefNotFoundErrors, even though you are detecting & avoiding the usage of 1.4 classes.
You can work-around this issue by using Reflection and avoiding any symbolic references to 1.4 classes in your code.
[ November 07, 2002: Message edited by: Junaid Bhatra ]

We are having the same problem too.
WAS 5 beta is not available for download. WSAD 5 is not available for download yet(not even the trial version). WAS Technology for Developers is too old a release to be testing your stuff on (more than 7-8 months old). So the only choices available if you need to test your application on WAS 5 are:
1)Shell out a few thousand bucks for WSAD 5
2)Wait until Dec (or gawd knows when....IBM has already delayed the release of 5 before).
This after the fact that we are an existing 4.x customer and would like to move & test our J2EE 1.3 stuff to WAS 5. IBM really drives me nuts sometimes too!
WebSphere is probably the *only* appserver today which does not have a production J2EE 1.3 compliant version. So much for being the first!
[ October 31, 2002: Message edited by: Junaid Bhatra ]

To answer some questions:
1) The platform default encoding can be obtained by System.getProperty("file.encoding")
2) Cp1252 is the Windows character set (code page 1252). It's very similar to ISO-8859-1 (Latin 1), but is not identical. For eg, in Latin 1, characters in the range 128-159 are control characters (non-printable). However 1252 assigns some printable characters (such as the TM symbol) to codes within this range. So CP1252 is kind of like a superset to Latin 1.
3) I think there is some confusion here regarding "character sets" & encodings. UTF-8 is simply an encoding scheme (i.e represent characters as a sequence of octets), and is used to encode the Unicode "character set". Character sets on the other hand is a mapping between "charaters" and "character codes"/integers. Additionally a charcter set may specify an encoding scheme(s). For eg, Unicode has UTF-8 and UTF-16.
Also it's important to remember that beyond US-ASCII (i.e character codes > 127), all other encoding schemes (like Latin 1) are incompatible with UTF-8. This is because UTF-8 is a multi-byte encoding scheme which encodes characters like:
One byte 0xxxxxxx - 0 indicates single byte used for encoding the character
2 bytes 110xxxxx 10xxxxxx - 11 in the first byte indicates 2 bytes used for encoding
3 bytes 1110xxxx 10xxxxxx 10xxxxxx - 111 indicates 3 bytes used for encoding the character
On the other hand, Latin 1 encoding is pretty straight-forward....simply write out the character code value (1 byte). Thus for character codes 128 - 255, Latin-1 uses 1 byte for encoding while UTF-8 uses 2 bytes.
To add to the confusion, the "charset" header that is used in HTTP is really the encoding that the web-page employs & not the character set. :roll:
[ October 31, 2002: Message edited by: Junaid Bhatra ]

Vanin,
One of the best resources for learning Schemas that I found on the net is Roger Costello's Schema tutorial. Check it out if you are interested.
Also, believe it or not, W3C's Schema primer is quite readable too.

Yep Server "A" is indeed WebLogic 7.0. If you download the sourcecode, you will see weblogic.xml DD's all over the place.
Server "B" is widely believed to be WebSphere [Hint: IBM's JRE was used for testing server B. Also AppServer B did not support EJB 2.0/local interfaces, which ties in with the fact that WebSphere 4.x does not support EJB 2.0].

Instead of writing your own Classloader, I guess you could use the built-in URLClassLoader for the same purpose:
URL[] urls = new URL[]{new URL("file:myDir/")}; URLClassLoader loader = new URLClassLoader(urls); Class c1 = Class.forName("com.foo.myClass", true, loader);

To answer your original question, DTD's have been around a lot longer than schemas. There are lots of applications out there using existing DTD's, and organizations are usually reluctant to re-write working stuff, unless there is an absolute need. However, Schemas do have a lot of advantages over DTD's, like true support for namespaces, support for datatypes (not just PCDATA/strings), and regular expression-like syntax for constraining your documents, among other things.
Even though DTD's do not have an XML-like syntax, they are pretty easy to use. Schemas on the other hand are extremely powerful, but have a lot more complexity. Ever tried reading the Schemas specification, Schemas Part 1 and Schemas Part 2?
Schemas is not just to way to constrain/validate your documents, but is a language in itself, and is an indispensable part of the WebServices/SOAP initiative. IMHO, it is the way to go, and will eventually replace DTD's but it might take a while.
[ October 29, 2002: Message edited by: Junaid Bhatra ]

<xsl:template match="item[text()='System Admin']">
This will match an item node with text content of System Admin.

WebSphere has a similar feature, called as Custom Services. But unlike WebLogic, in which you can give any arbitrary class file with a main() method, the custom service in WebSphere *has* to implement a specific interface. When the application server starts up, it will call a particular method on your class. Search the WebSphere docs for specifics on this.
However you must be careful in using this WebSphere feature. WebSphere makes no guarantee about the order in which this custom service will be called. Also there is no guarantee that any app-server services (eg, JNDI naming service, Connection Pools) will be fully initialized when your custom service is called. So if your custom class needs to lookup, say a JNDI reference, it may not be available!
As someone else suggested, the cleanest way is to implement a startup servlet, which simply calls your custom class within the init() method. Using this approach, it is guaranteed that the app-server services will be fully initialized by the time the servlet is loaded.