Kamal Wickramanayake

But it helps not me nor others.

I don't agree. What I gave is a very specific answer for the issue you are having. And it was for a specific part of your problem identified by the quoted text. When someone answers a question with 'yes', it doesn't mean that 'yes' is a generic answer and not acceptable for the question asked just because 'yes' can be used to answer an infinite number of different questions.

May others assist you.

I haven't used HTMLUnit. But instead of

//Webpage only accessible to logged in users URL+private.php
printWebpage("http://www.honda-tech.com/private.php");

what if you try something like

HtmlPage page2 = webClient.getPage("http://www.honda-tech.com/private.php"); System.out.println(page2);

I don't think accessing outgoing http headers is feasible. It's because they are added by the application server to the final output. Using an Axis2 handler you can however access the entire SOAP response (including SOAP headers). If you want to access outgoing http headers, look at how you can do it in your application server. You may also use a proxy server for the same purpose.

<table style="display:block">

I doubt if you can do like that. Try <table style="display:table">

To support the pages, you use managed beans which are simply known as backing beans (since they support pages). You may be able to use one backing bean to support couple of views if your views are not that complex. Otherwise you will write one backing bean for one view. Less is good if you can do it without diluting the focus of the backing bean.

For data access from the database (CRUD operations), you may use other managed beans. Such a bean will be used in many other places (many other managed beans). It's just implementing good separation of concerns.

You can have a look at this which illustrates the above points: Best way to use JPA in web-tier

Yeah you gave me a good idea, im gonna set a flag with a dateTime in the DB to know if my application its running, so my App will report to the DB, and my JSF page would look it up. And start the Application with a call to the system from the manageBean, that if the App its not running.

I doubt if you really should do it that way. I thought your regular app is to run probably in another machine. It seems you want it to start via your web application. May be you should just integrate it to the same web application by not using a system call. You should be able to easily do it with a new web application lifecycle listener (configured via web.xml). When the application server starts up, the listener gets notifications. You trigger the execution of your multiple threads from there. You can set a flag just on the Servlet context (setAttribute). Your JSF code will also be able to check if the flag is set or not (getAttribute).

This way, you don't need to depend on remote interface of the EJBs. You can access them (from your multi-threaded code) in the same way you are accessing them right now from JSF.

Did you correctly engage your module in the in-flow handler chain?

But meanwhile I am just left confused with all the interaction of renderers, editors, values and defaultstuff, that I would be very, very pleased if there is (/are) someone, that can explain to me the cooperation of CellEditors, DefaultCellEditors, DefaultTreeCellEditors, CellRenderers, DefaultTreeCellRenderers and

Look at The Java Tutorial. These are nicely explained there.

1. can i access the EJB's on my EE project from my regular application to access the database?

Oh yes. That's what EJBs are meant for. In your client code you perform JNDI lookup to access the Remote Interface of the EJB. Then you just call the methods.

2. How can i tell to my JSF page that my regular application its actually running?

If that is needed you might maintain a flag in the DB. Generally there's no need to do things like that. You might be having a special requirement.

Stub class is only to be used by the client. Skeleton is only to be used to develop the service. MessageReceiverInOut is used to act as a bridge between the Axis2 engine and the service skeleton instance. In terms of Axis2 message processing details, Axis2 core engine assumes that a message is processed to conclusion when a message receiver is invoked. MessageReceiverInOut is one such message receiver that can receive a message as well as generate a response. You don't have to worry too much about it.

A call back handler is used if you develop asynchronous clients/services. It's used at the client side. With asynchronous mode, client sends the request and continues doing work. When the server sends a response, the call back is used by the client to handle it. In this mode you can even use two TCP connections. Mostly you write synchronous clients/services.

Look at the wsdl2java command line parameters. You can separately generate the skeleton code in one directory, finish and deploy the service. Then you can use the same command to generate the client only code (say only with synchronous mode stub code) and get the client completed.

Here you find some details about Axis2's Spring support: Axis2 Spring support

If you wouldn't mind, could you please tell why you want to access this object?

Was tied up with work and hence couldn't respond quickly.

Here's one issue in detail: Apache Axis2 WS-Security message signing vulnerability (Version 1.5.1)

Hm, I don't see anything resembling either of these two statements in the links you posted. Also, "to prefer WS-SecurityPolicy over WS-Security" does not make sense, since WS-SecurityPolicy is used to specify how to apply WS-Security (amongst other things).
If this is just about changes in the way something is configured, then that has no impact on the actual security provided. Rampart itself is certainly not deprecated or obsolete.

What you say is very correct. I got it written in the wrong way. It's a configuration matter. At the beginning there was WS-Security support which required you to configure using the previously said "parameter based approach". What they deprecated was that "parameter based approach". Then the WS-SecurityPolicy based approach was introduced. The plain and dominant approach used by many to configure WS-Security was the "parameter based approach". That's what was in my mind and the cause for my error. Thanks for pointing out.

As said, I'll send evidence showing the issues with both "parameter based approach" and WS-SecurityPolicy based approach.

Unless you have actual evidence that Rampart does not provide the security it claims to provide...

"WS-SecuityPolicy is preferred over WS-Security" is their statement. WS-Security was deprecated and there were reasons behind. What I don't know is if they reversed in version 1.5.

"Axis2 security is broken" is my comment. But I never said anything without facts with me. Wait for a day or two. I'll also try with their latest version.

I strongly suggest to stay away from the kind of advice you gave

"Don't do something" is as good as "do something" I know, you need evidence when the advice goes against what is generally accepted, which I am going to send.