For standalone deployment, where is the Jetty configuration file?

[Anonymous]

I have a Talend ESB (v5.3) job that exposes a web service (using a tRESTRequest component). I do NOT deploy this job using the ESB Runtime (we had issues with using Karaf in our circumstances), but simply export the job as an autonomous (i.e. standalone) application.
I desperately need to configure some aspects of Jetty (SSL related info) and, for the life of me, can't figure out what config file is used to configure Jetty for an autonomous job. I know that for jobs deployed to the runtime, "Runtime_ESBSE\container\etc\org.ops4j.pax.web.cfg" is used, but I'm assuming that file is not used for standalone deployments.
Thank you so much for your help.

[Anonymous]

You need to start your Karaf before the Jetty.xml file is created. The first startup creates a few files and the Jetty.xml file is one of them. To start the Karaf, use the command line and navigate to your /Runtime_ESBSE/container/bin folder. Run the trun.(bat/sh) file. It will take a while to start. Once it has go to the /ESB/Runtime_ESBSE/container/etc folder and you will see a Jetty.xml file there.

[Anonymous]

I appreciate the quick response, but I want to make sure you understand that I do not run my job within Karaf--it's an autonomous (i.e. standalone) job.
Are you implying is that, even as a standalone job, the Jetty.xml file (created via your procedure above) is added to the generated job files and used by Jetty? I hope that's what you're implying, as that would certainly solve my problem.
Thanks again.

[Anonymous]

Sorry I misunderstood. I am curious, have you managed to get this running because it shouldn't work. The "Standalone Job" option when building is not meant for web services. It is meant for Talend Data Integration jobs. Unfortunately I only have v6.0 on my machine at the moment but was curious so built a REST service and tried to build it as a Standalone Job. It doesn't permit it. Maybe 5.3 does. To be honest I never tried.

[Anonymous]

We simply export the job using the settings shown below and launch it in a command window. It supports jobs with REST services (typically using  tRESTRequest) with no issues. We have several production deployments that use this approach.
We couldn't use Karaf because, under Karaf, Talend doesn't consistently implement component properties specified via underlying Java--an absolute requirement for us.
Is there any hope that the Jetty.xml file is still used in standalone mode?

[Anonymous]

I'm surprised this works if I am honest, but I will take your word for it and try it out later. I would advise against this though. Running through the Karaf (or Tomcat maybe?) is a much safer and more stable option. However, that was not your question. Since Jetty works by establishing a "home" location for the distribution and then basing the rest of the required files relative to this, I would try the following.
Your "home" location will be the folder holder the "lib" folder which holds the Jetty-*.Jar files. In that "home" folder, create an "etc" folder and place a Jetty.xml file in there. I can't promise this will work, but given the what Jetty expects, that would be the first place I would try.
By the way, what exactly did you mean by " Talend doesn't consistently implement component properties specified via underlying Java"? I suspect that this could just be a configuration issue. Configuring the Karaf can be a bit daunting and is somewhat hard to figure out if you are learning off your own back. Of course that is the best way to learn any Apache product 🙂 Maybe we can help you get Karaf up and running as you wish. 

[Anonymous]

Thanks so much for this information. I will give it a try and let you know what happens.
When I said "Talend doesn't consistently implement component properties specified via underlying Java," here's what I meant. Under most circumstances Talend component fields can be set using either constants or values (typically derived from sort of Java call) that are evaluated at runtime. Because we have a fairly sophisticated Java architecture (implemented in classes under Routines, and including heavy use of Google Guice for dependency injection) that most of our Talend components delegate to, it is critical that we be able to set virtually any component field via a method call. What we found, surprisingly, is that there were some Talend components that didn't evaluate their fields at runtime when running under Karaf. 
I posted about it here:  https://community.talend.com/t5/Design-and-Development/Serious-tRESTRequest-bug/td-p/110527 and created a JIRA issue here  https://jira.talendforge.org/browse/TESB-10014. Unfortunately, it's not clear from the issue log whether it was ever resolved (though it was closed).
Unfortunately for us, this bug means Karaf is simply a non-starter.

[Anonymous]

The problem of not being able to set the tRESTRequest Endpoint URL intrigued me, so I installed an old 5.4.1 build on my machine and took a look. I *think* I might have a workaround for you. You will need to see if it suits your needs of course.
A common problem with Routes and Services run in Karaf is that context variables are not always initiated before things like Endpoints are. You actually see the same thing if you try and do a context load of the AMC database details in normal Data Integration jobs. A way around this is to put the job (or service in this case) inside a wrapper job and pass the context from the wrapper job to the inner job. 
My wrapper job looks like below....
I create a context variable called "port" and assign it a value here. I then supply it to the "port" context variable of the service.
My service (a very basic one) looks like below....

I built the wrapper job as an OSGI BUndle for ESB and then deployed the job (service) in the ESB deploy folder. I then tested the service and the Endpoint (which was computed from hardcoded text and a port supplied as a context) was correct. The service worked.
I haven't had time to test this solution exhaustively, but following what you said and from reading the Jira, it looks like this might work for you. I'd be interested to hear if it works.

[Anonymous]

I'm not really sure your Karaf issue is a bug. However, to answer your question, I think you would need to modify the component. It uses the AbstractJAXRSFactoryBean to create the server, the generated code in the standalone job for the server looks like this: 

org.apache.cxf.jaxrs.JAXRSServerFactoryBean sf = new org.apache.cxf.jaxrs.JAXRSServerFactoryBean();
                                java.util.List<Object> providers = new java.util.ArrayList<Object>();
                                providers
                                                .add(new ExceptionMapper4TalendJobRestService(provider));
                                providers
                                                .add(new org.apache.cxf.jaxrs.provider.dom4j.DOM4JProvider());
                                org.apache.cxf.jaxrs.provider.json.JSONProvider jsonProvider = new org.apache.cxf.jaxrs.provider.json.JSONProvider();
                                jsonProvider.setIgnoreNamespaces(true);
                                jsonProvider.setAttributesToElements(true);
                                providers.add(jsonProvider);
                                sf.setProviders(providers);
                                sf.setTransportId("http://cxf.apache.org/transports/http");
                                sf.setResourceClasses(RestServiceProviderImpl4TalendJob.class);
                                sf.setResourceProvider(
                                                RestServiceProviderImpl4TalendJob.class,
                                                new org.apache.cxf.jaxrs.lifecycle.SingletonResourceProvider(
                                                                provider));
                                sf.setAddress(endpointUrl);
                                final java.util.List<org.apache.cxf.feature.Feature> features = new java.util.ArrayList<org.apache.cxf.feature.Feature>();
                                features.add(new org.apache.cxf.feature.LoggingFeature());
                                sf.setFeatures(features);
                                server = sf.create();

What you would like to do would be able to pass a configuration in, probably a spring bean Bus as outlined here: http://cxf.apache.org/docs/secure-jax-rs-services.html 
So a little hacking on the template will be required. 
As to it not really being a bug, check out this thread : https://www.talendforge.org/forum/viewtopic.php?id=45530
  The issue in Karaf is that the Jetty instance is already there and it's trying to override your endpoint since its already configured . Any absolute paths either are ignored or cause an address already in use(or obviously some wackiness when context vars are in there), if you need to change the endpoint you would typically do it in the Karaf jetty config and the CXF. I'm not sure if there is a way currently to have CXF stuff deployed in karaf to have dynamic ports and endpoints but if you do figure it out, I bet it will probably break the monitoring, authentication and locator and everything else Karaf can do when you let it manage the CXF stuff.