You might have faced to download gigabytes of repositories with Hg. In my case, a big portion of Mozilla repositories depends on it and wanted to download that huge repos from the university network. University bandwidths are mostly underused 😉
Hg uses hgrc file to load configurations. (Per repository) You can go to your repository, .hg/hgrc and add following with your configurations.
host = your.proxy.host:8000
passwd = password
user = username
In case you are using hg from a preloaded instance to clone repositories to another location, you can simply add your configurations as a prefix to your command.
Make sure if you have special characters(@,%,,.) in your username or password you use the suitable character representation for it. ie : use %40 instead of @ symbol. This will also help in finding special character representation.
Axis2 handler is the smallest invocation unit of the axis2 engine, which has ability to intercept into the message flow during the runtime and operate read/write operations on an incoming or outgoing message. i.e: if you need to route messages coming with specific attributes to a different end point or count the number of messages with that attribute you can simply make use of axis2 handlers. Since, handlers has that ability of intercepting to message flow and read/write to message context, inherently they are capable of suspending the message flow.
Axis2 handlers give you full authority over SOAP messages travel through. As a result of that super control, handlers can add additional headers to SOAP message, add body content and read the message header or the body.
Specially, when implementing ws-reliableMessaging handlers can be used to control the flow of the message. if the message supposed to be delivered second, arrives first it can be hold till the first message arrives and then it can be send to execution.
Inbuilt axis2 handlers
Axis2 comes with a list of inbuilt handlers to implement ws-* and other functionalities like parsing headers.
LoggingModule.java No implementation in this class at the moment.
“module.xml” contains the deployment configurations for a particular module. It contains details such as the Implementation class of the module (in this example it is the “LoggingModule” class and various handlers that will run in different phases). The “module.xml” for the logging module will be as follows:
InFlow – Represents the handler chain that will run when a message is coming in.
OutFlow – Represents the handler chain that will run when the message is going out.
OutFaultFlow – Represents the handler chain that will run when there is a fault, and the fault is going out.
InFaultFlow – Represents the handler chain that will run when there is a fault, and the fault is coming in.
Then you can modify the axis2.xml in order to introduce LoggingModule to the axis2 engine. Here we have defined a custome phase named LoggingPhase here.
After the module is built, you may place the .jar or .mar (rename the jar file) and keep in your library dir WSO2, (repository/components/lib).