• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JAX-WS and undesired exposure of properties

 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there any way to create a class that can be unmarshalled without exposing properties that I'd rather not make available via a public set method? I guess this is really a bean question, but I ran into it trying to create a web service.

For example, in the following class, I'd rather not have the setKids method public, since it would allow for wholesale replacement of the field after the object after it is created:



I can see several solutions, but each has some flaw:

1. have the method only store the value if the field is not null (and remove the initialization of the field and move it to the parameterized constructor) - the flaw here is really with the general bean concept of having a no-args constructor, which I would normally not want for this class, since it would allow creation of an instance in what I would consider an inconsistent state; e.g., having only a first name and not a last name

2. create a "dummy" parallel class which I can receive, and then have a constructor or factory method that accepts an instance of the dummy class and transfers the data to a real instance, perhaps throwing an exception if the necessary fields are not populated. I don't see any major issue here, but it seems like a lot of work to go through.

3. Have every method in the class that I might call on a complete object check for internal consistency - seems very inefficient, although this could be relieved somewhat by having a flagging system that I could use to mark that a set method has been called once.

Are there other solutions I haven't thought of?

Or, is there some annotation scheme for constructors that I am unaware of? It seems that there could be an annotation for constructor parameters that would specify what field they map to, so that instantiators could use a parameterized constructor.

 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is this class the service class, meaning, does it have a @WebService annotation? If so, you can use the @WebMethod annotation to indicate those methods that should be exposed. Or is this more of a JAXB question?
 
steve claflin
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's really more of a bean question, since the same issues would come up with any bean, perhaps instantiated via <jsp:useBean /> in a JSP. But, in this case, it is the return type from a WebMethod, as in my simple test program:



I didn't get the kids in my returned Parent data until I added the setKids method to Parent, which was the method I was trying to avoid having publicly available.
 
steve claflin
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Found javax.xml.bind.annotation.adapters.XmlAdapter, which does the trick in the fashion of my original solution #2.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic