Bob Nedwor

Thanks for explaining.
I think I need more practice with Typescript and I should purchase Vlad Riscutia's book, Programming with Types!

So "let" is a valid key word in ES2018?

Ok thanks.
I think I see what you are saying.

So in some cases, the --target simply works as more of a pre-step?

Thanks, everyone but I thought that the idea of tcs is to transpile TypeScript into Javascript. It works great without the --target option.
The default is ES3.

Try
  tsc --all
to see all the options
-t VERSION, --target VERSION                       Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019' or 'ESNEXT'.

Here is my .tc file ( other than the empty lines, the same as the output .js file when I use the -- target):
consman01@BobsBonoboExtreme:~/tspractice$ cat a.ts const message: string = 'hello world'; console.log(message); class Foo {    constructor() {        alert('we are running foo..');    } } let fooImpl = new Foo(); consman01@BobsBonoboExtreme:~/tspractice$

Can anyone get it to work with any of the VERSION values? other than the default?

I can't seem to get the -t / --target option to work. I have tried
 --target 'ES2018'  
 --target ES2018
 --target "ES2018"
  -t 'ES2018'
  -t "ES2018'"
  -t ES2018
and with other values like ES2016.
Each time tsc seems to do nothing other than put the contents of the .ts file into the .js file - without even an error message

consman01@BobsBonoboExtreme:~/tspractice$ tsc --version Version 3.5.3 consman01@BobsBonoboExtreme:~/tspractice$ rm a.js consman01@BobsBonoboExtreme:~/tspractice$ tsc --target 'ES2018' a.ts consman01@BobsBonoboExtreme:~/tspractice$ cat a.js const message = 'hello world'; console.log(message); class Foo {    constructor() {        alert('we are running foo..');    } } let fooImpl = new Foo(); consman01@BobsBonoboExtreme:~/tspractice$ consman01@BobsBonoboExtreme:~/tspractice$ rm a.js consman01@BobsBonoboExtreme:~/tspractice$ tsc a.ts consman01@BobsBonoboExtreme:~/tspractice$ cat a.js var message = 'hello world'; console.log(message); var Foo = /** @class */ (function () {    function Foo() {        alert('we are running foo..');    }    return Foo; }()); var fooImpl = new Foo(); consman01@BobsBonoboExtreme:~/tspractice$

Can someone explain what I am doing wrong?  
Thank you.

Welcome, Vlad. Thanks for creating a well-needed book. Strongly-typed is the only way to go!

I agree with Deriko. Ejb certification is easier. Of course it depends on your geographic area, but I think the Web Services certification is more marketable, not just because is it more difficult, but also because more people are starting to use Web Services and Web Services-related skills are appearing as required and preferred in an increasing number of job postings. I am going for the Web Services cert, then maybe the EJB cert later.

Thanks to Milan Kuchtiak for the example previously referenced. I also changed my package from the default (none) to "name" like he did and I also added the ApplicationConfig class like he did (to demonstrate that not even a web.xml is necessary here). I rejarred and re-deployed.

What Milan does not show you is how to call these using curl (in case you do not want to go to the trouble of setting up NetBeans 6.8, etc). Here they are:

curl http://localhost:8081/restejb/resources/application.wadl
curl http://localhost:8081/restejb/resources/name
echo "New Name" > data
curl -T data http://localhost:8081/restejb/resources/name
curl http://localhost:8081/restejb/resources/name

Abayomi;

There are quite a few different ways to do this. Please check out the "wsimport" options. As long as you have your Java 1.6 $JAVA_HOME/bin in your $PATH environment variable, just type
"wsimport" from your command prompt (I think it is %JAVA_HOME%\bin in your %PATH% in Windows). If you do not have JDK 1.6, then wsimport should be in the bin directory in your jaxws-ri or glassfish3/glassfish directory, depending on how you are learning java web services.

If the cold fusion service that you are talking about is up and running and working as a real SOAP Web Service, then there should be a navigable WSDL you can see in your browser somehow ( http://localhost:8080/mycoldfusionservice?wsdl or something like that) that describes the operations, ports, messages, etc., of your service.

Once you know what it is, just create two folders, "src" and "bin", then say:
wsimport -keep -s src -d bin http://localhost:8080/mycoldfusionservice?wsdl (you might need to try this a few times using the -p option with the right package name before you actually get what you need).

Once this works, you have nearly everything you need for your client, but your class with the main method. You have to build that yourself, using a few lines of code that create an instance of the generated ?*Service.java class that wsimport gave you, then call its "get?Port()" method. See http://www.javadb.com/create-a-web-service-client-with-jax-ws for an example of how to do this.

I hope this helps.

It seems that at least part of the answer is here http://netbeans.dzone.com/articles/how-to-combine-rest-and-ejb-31 .

My NameBean needs @Singleton and some other things.

More on this later.

Thanks if anyone has any other answers.

Bhanu;
I would stay away from "J2EE Web Services: XML SOAP WSDL UDDI WS-I JAX-RPC JAXR SAAJ JAXP" because it sounds like it is based on the old jax-rpc standard.

Starting with JEE 5, jax-rpc was replaced witth jax-ws and jaxb.

Java Web Services: Up and Running by By Martin Kalin is much more useful for OCPJWSD 6 certification. I have that book and I really like it.
Also, please get "SOA Using Java Web Services" by Mark Hansen, which I also have and like that one even better.

I think I might be doing something wrong.
I am trying to get the NameService example from http://java.boot.by/ocewsd6-guide/ch04.html to work on Glassfishv3 and I am not sure I am deploying correctly.
I cannot seem to find the code for the NameBean class, so I made up my own.
When I deploy, the server log seems to indicate that everything is going OK, but I am not sure what URLs to try with my curl command.
(I run Glassfish on 8081).

curl http://localhost:8081/restejb
just gives me my prompt back.
Pretty much everything else gives me: HTTP Status 404 The requested resource () is not available.

Thanks to anyone who can help me with this. Here is what I am doing:


$ cat src/NameService.javaimport javax.ejb.Stateless; import javax.ejb.EJB; import javax.ws.rs.*; @Path("name") @Stateless public class NameService { @EJB private NameBean nameBean; @GET @Produces("text/plain") public String getHtml() { return "Hello " + nameBean.getName(); } @PUT @Consumes("text/plain") public void put(String content) { nameBean.setName(content); } }

$ cat src/NameBean.java
public class NameBean { private String name; public String getName(){ return name; } public void setName(String inName){ name = inName; } }

$ mkdir WEB-INF
$ mkdir WEB-INF/classes
$ export GL4=/bapps/glassfish3/glassfish/modules
$ javac -cp WEB-INF/classes:$GL4/javax.ejb.jar:$GL4/jersey-core.jar -d WEB-INF/classes src/*.java
$ jar cvf restejb.war WEB-INF
added manifest
adding: WEB-INF/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/NameBean.class(in = 394) (out= 249)(deflated 36%)
adding: WEB-INF/classes/NameService.class(in = 894) (out= 527)(deflated 41%)
$
$ cp restejb.war /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war
$

Server log then says:

[#|2011-04-18T09:50:27.606-0700|INFO|glassfish3.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=63;_ThreadName=Thread-1;|[AutoDeploy] Selecting file /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war for autodeployment.|#]

[#|2011-04-18T09:50:27.937-0700|INFO|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=63;_ThreadName=Thread-1;|Portable JNDI names for EJB NameService : [java:global/restejb/NameService, java:global/restejb/NameService!NameService]|#]

[#|2011-04-18T09:50:28.048-0700|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=63;_ThreadName=Thread-1;|WEB0671: Loading application [restejb] at [/restejb]|#]

[#|2011-04-18T09:50:28.090-0700|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=63;_ThreadName=Thread-1;|restejb was successfully deployed in 434 milliseconds.|#]

[#|2011-04-18T09:50:28.097-0700|INFO|glassfish3.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=63;_ThreadName=Thread-1;|[AutoDeploy] Successfully autodeployed : /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war.|#]

After looking at this more closely, it seems that there are two ways to do this without having to create a BindingProvider, manually messing with SOAP elements, etc, like I mentioned in my previous post. But neither one results the namespace being defined in the header of the Envelope like in Dan's 03/29/2011 11:02:32 AM example above. Instead the namespace is defined within the individual elements. Also, neither one results in a MessageID element being created - just "To" and "Action."

a) On your server-side implementation class, use this annotation:
@com.sun.xml.ws.developer.MemberSubmissionAddressing(enabled=true, required=true)
and in your client code, pass an instance of
com.sun.xml.ws.developer.MemberSubmissionAddressingFeature(true, true)
into your getXXXXXport() method.

b) On your server-side implementation class, use this annotation:
@javax.xml.ws.soap.Addressing(enabled=true, required=true)
and in your client code, pass an instance of
javax.xml.ws.soap.AddressingFeature(true, true)
into your getXXXXXport() method.

One difference between a) and b) is that in order to compile the classes in option a) you need to add to your classpath a jar from either your jaxws-ri or glassfish apps whereas in option b) you do not (if you are on JDK 6).

The other big difference is that in option a), your "To" and "Action" elements in your SOAP header are using the http://schemas.xmlsoap.org/ws/2004/08/addressing namespace where as in
option b), they are using the http://www.w3.org/2005/08/addressing namespace which seems to be more recent.

I am not sure which option a) or b) above is considered more "WS-Addressing Compliant," but I suspect that I am still missing something and I would appreciate advice as to how to get the MessageId element in along with the other two, and get my namespace defined once up in the header of the Envelope and still not have to create a BindingProvider, etc, like I mentioned in my previous post. One further note is that I did not tweak my WSDL, in either option, and it has no WS-Addressing-related items in it.

Thanks.

I was able to get it to work, but it was more than a couple tweaks to the WSDL. To get my request side SOAP message (inbound to the service) to look like this, I needed to hack up my client quite a bit, including casting my service to a BindingProvider, create a SOAPHandler and mess around with the SOAPHeader, SOAPEnvelope, etc. Is there a faster way to build WS-Addressing into your client side that you know of off hand? Thanks for your advice.

Thanks, that is great, Dan!

Can you show us the related WSDL? Or at least the portType and binding sections of it?

1. Is it a valid include since in first include http://soabook.com/example/oms/orders.xsd has targetNamespace="http://www.example.com/oms" and the WSDL's targetNamespace="http://www.example.com/req". Same is the case with second include as well.

This is valid. You are using xs:include and xs:import (as they are defined in http://www.w3.org/2001/XMLSchema).
The example is NOT using the WSDL version of import. So I do not understand the nature of the first response.
The example comes from Mark Hansen's Great book, www.soabook.com, so as long as you did not alter it, you can bet it is valid.

2. I checked this WSDL is working fine with wsimport tool so wondering, how is the targetNamespace="http://www.example.com/oms" being referenced here. Is it because of the enclose <xs:schema> element which defined targetNamespace is also importing it?

This is a good question. I am not certain, but it looks like you are right. It appears that a new <schema> enclosure requires us to
import the namespace, even though xmlns:oms="http://www.example.com/oms" is already defined up in the header of the main WSDL.