• Post Reply Bookmark Topic Watch Topic
  • New Topic

Axis2 creating undesireble fields in types  RSS feed

Hikari Shidou
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello guys.

I'm using Axis2 to create WebService. I create a Java class and use it (from eclipse) to create the WS.

My issue is that I like to use Broker pattern in my softwares, to interface Application and UI. Throu the Broker, Application provides services that UI calls. In Java, this Broker is an Interface and Application provides a basic implementation that handles each service and calls Application's components to do the job. UI, then, uses its own Broker implementation or uses this basic one. When I have to handle multiple users, each user has its Broker object/session, that holds user's authentication and other states.

When I use a WebService as interface for UI, my plan was keep the same behavior, creating a class that implements Broker and has all its services, and give it to Axis2 create the WS. Each App service will become a WS operation.

The issue is that some Broker's operations receive beans as parameters, and these beans may have methods meant to do some small processing into some property, and not be a property itself. And when Axis2 creates the WS, these beans become types, and these methods are interpreted by Axis2 as properties.

For example, in a test I was doing, a method receives an AuthenticationInfo bean as parameter. That class was therefore added to WSDL. But for testing it had a getPasswordTruncated() method, that returns the upperlettered first letter of password. Axis2 thought it was a property and turned it into a type's field, which could be setted and getted separated from getPassword()!

In the same way, what happens if the class I use to create the WebService has a method that I don't want becoming a WS operation?

Is there a way to tell Axis2 that something should be ignored? Or would the only solution be creating a proxy class for WS creation, that calls the real class? That's kinda troubling, because if original class implements an Interface, proxy class won't be allowed to do so. And if it has many operations which use many beans with this issue, I could have to recreate a lot of beans. That breaks maintainability!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!