We Keep Coding

Why we need ibm-web-bnd.xml and ibm-web-ext.xml?

Why we need ibm-web-bnd.xml and ibm-web-ext.xml in application that we need to run in WAS server. I found few things like it contain virtual host , context root etc. But i want to know why it is required for WAS server.

First of all they are not required, they can be generated during the installation for example via web admin console. However they can provide some predefined settings or change the default behavior.
The ibm-web-bnd.xml file provided binding between resource references used in web module and actual components, like datasouces, queues, etc. However since Java EE 6, you can actually use the lookup attribute from the #Resource annotation to provide them in the code. See some more info about bindings here - Application bindings
The ibm-web-ext.xml file allows you to configure some settings for web module e.g. context-root, directory browsing, etc and JSP engine parameters.
The easiest way to create them is to use WebSphere Developer Tools for Eclipse (free plugin), which have graphical/text editor for them.

Does Artifactory store whole configuration in artifactory.config.latest.xml?

I am using Docker and NuGet repositories in Artifactory. Current Artifactory REST API does not support every option on Docker or NuGet repositories.
It looks like the whole configuration created by calling appropriate REST API calls is stored in a file called artifactory.config.latest.xml.
Is it safe to restore the whole repository configuration just by copying that file?

The artifactory.config.xml that's stored in your filesystem is there mainly for recovery scenarios, although it is perfectly usable, yes.
The thing is, is that you have to restart your instance to have the filesystem changes re-imported into Artifactory (you also need to rename the file to artifactory.config.import.xml for Artifactory to pick it up at startup).
If you're looking for and option to modify repository configuration (or any other configuration Artifactory has for that matter) during runtime you can use this api which retrieves and persists the config.
It's perfectly safe to use as it represents all of the available configuration for all of your repos and the global configuration parameters as well.
Do take care though - it's always a good idea to backup a known working copy before you start playing around - there's no undo button.
Also, this configuration is subject to change as versions progress - you can always consult the config schema if you get lost (note the version - that's the one you have at the top of the xml file declaration).

felix exthttpservice set session path for cookies

I have a webapplication that I am running in Felix osgi container. I am using jetty as the implementation for the extHttpService. Currently it is writing the cookies to the '/' root path. I would like to change this as it is causing conflicts with other web applications. Looking at jetty documentation it appears I need to set the following property.
org.mortbay.jetty.servlet.SessionPath
However, I am unable to find a way to set this using the ExtHttpService via osgi. I have tried creating a jetty.xml file, adding this to the config.properties, and setting it as a property in the call to register my servlet.
Does anyone know how to set this?
thanks,

I actually ended up patching the source for my current implementation, but on the mailing lists here, a patch has been submitted that should allow this to be configurable.

Apache vs Tomcat configuration question

I was searching in Google and found that Apache can be configured via mod_access directives in the httpd.conf file to block a web site from a particular IP.
Is there anything equivalent in Tomcat?
I am not sure I understand what are the corresponding configuration files.
Thanks

Try the Remote Address Filter. http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html

See the Request filters section of this doc. Doing this via tomcat configuration is pretty static, you need to restart to edit configuration. If you need something dynamic, it's probably best to implement a custom servlet filter.

SSL Connection problem to web service from Java bean

I have written an application that connects to a SSL web service (including client certificate) through jaxws. For this to work I have a wstrust.jks that contains trusted root certificate for ws, and client.p12 that is the client certificate to use when connecting to ws. I have then created a custom SSLSocketFactory to be able to use my wstrust.jks and client.12 during the connection to ws. I tell jaxws to use my implementation by:
[javax.xml.ws.BindingProvider].getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY, customSSLSocketFactory);
Everything works like a charm if i run it as a standalone java-application. However when i use the same technique inside a Java bean (JSF) deployed as a war-file running under Tomcat,
i get a "PKIX path building failed"-error.
BUT If i configure SSL through JAVA_OPTS when i start my Tomcat (through the -Djavax.net.ssl.* parameters) I get it to work.
So my question:
How do i (or is it possible) to get my custom-SSLSocketFactory-technique to work inside the Java bean?
I guess as tomcat wraps itself around my application, when running as a bean, it is working differently and my wish to use a custom SSLSocketFactory isnt respected...
Thanks for any input on this!
/Tobbe

Solved it. If anyone have the same issue here is how. Instead of setting my custom factory through:
[javax.xml.ws.BindingProvider].getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY, customSSLSocketFactory);
I had to set it through:
HttpsURLConnection.setDefaultSSLSocketFactory(customSSLSocketFactory);
otherwise it seems to get ignored.
/Tobbe