Multiple Return Types

haven't been around in a while, so I thought I'd stir up some comments with a suggestion for a new feature in Java, which I'm sure has been suggested at some point, but I can't remember seeing it talked about, so here goes:
Multiple Return Types:
public String, int getStateInfo(String abbrev) {
   if("nj".equalsIgnoreCase(abbrev)) {
      return "New Jersey", 11408042;
   // ... and other states...
   return null, -1;
String name, int population = getStateInfo("nj");
System.out.println("The population of " + name + " is " + population + ".");Yes yes, I know. Create a StateInfo object with the fields needed. Still, I think that could be interesting.

apart from it getting ugly with more than twoparameters
What? How is this ugly? ;-)
public String, int, String, Color, String, String
getStateInfo(String abbrev) {
return name, population, stateFlower, stateColor,
or, stateAnimal, governorsName;
there no indication on what the return valuesrepresent.
Well, I guees the API docs would have to speak for
themselves. Or better method naming... In that
sense, it's no different then now. I could write a
method "getStateName()" and return totally different.
public String, int getStateNameAndPopulation(String
abbrev) {...
I used to like "tuples" when I studied The Tom Programming Language (that's how he calls them), as every CS student is a bit of a "featurist"... Now that I came to develop 40 hours a week and to love Java's simple and powerful expressiveness, I tend to find such constructs overly ugly to be avoided as possible... a matter of personal taste, too, I suppose...

Similar Messages

  • Flex services with multiple return types

    Hello,
    We are creating a webapplication with flex and php.
    Everything is working very good, until we got to the library part of the application.
    Every service so far had only 1 return type (eg: User, Group, ...)
    Now for the library we want to return a ArrayCollection of different types of objects. To be more specific the LibraryService should return a ArrayCollection containing Folder and File objects.
    But how to configure this in Flex (Flash Builder 4 (standard))?
    So far it converts every object to the type Object, i would really like it to be Folder or File
    The only solution we can think of right now is to create a new object Library that will contain 2 ArrayCollections, one of type Folder and one of type File. This could work ofcourse, but I wonder if there is a better solution for this OR that i can configure multiple return types for a service.
    Any ideas/advice is greatly appreciated.

    Normally if you are using Blazeds(Java stuff, i'm sure there should be something similar for php), you can map java objects to that of the AS objects, when you get the data back you are actually seeing the object which is a Folder or a File object rather than just a Object.

  • Exception in Holder for Multiple Return Types

    Hi,
    I am implementing multiple return types as mentioned at url: -
    http://e-docs.bea.com/wls/docs70/webserv/implement.html#1058020
    I have a "Ticket" object and its holder "TicketHolder".
    I have built the service successfully which has the following method with its
    built files: -
    public String serviceMethod(String arg,TicketHolder out) {
    Ticket tc = new Ticket();
    tc.setticketId("001");
    out = new TicketHolder();
    out.value = tc;
    System.out.println("got it man");
    return arg;
    But when i try to invoke this method from its "http://localhost:8088/WebServices/RegisterTickets"
    link (note - RegisterTickets is the service name here), it gives me the following
    exception at server side as well as client side: -
    javax.xml.rpc.JAXRPCException: Failed to invoke the target:test.MyService@630693
    operation name:serviceMethod method:public java.lang.String test.MyService.serviceMethod(java.lang.String,test.TicketHolder)
    args:[Ljava.lang.Object;@3d51e3arg.length:2 Due to exception:java.lang.IllegalArgumentException:
    argument type mismatch                                                      
                               at weblogic.webservice.component.javaclass.JavaClassInvocationHandler.invoke(JavaClassInvocationHandler.java:97)
                                                   at weblogic.webservice.core.handler.InvokeHandler.handleRequest(InvokeHandler.java:78)
                                                                             at weblogic.webservice.core.HandlerChain.handleRequest(HandlerChain.java:131)
        at weblogic.webservice.core.DefaultOperation.process(DefaultOperation.java:539)
      at weblogic.webservice.core.DefaultWebService.invoke(DefaultWebService.java:264)
    Can someone help me in resolving this exception?
    Any help would be appreciated...
    thanks in advance,
    Rajesh
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    apart from it getting ugly with more than twoparameters
    What? How is this ugly? ;-)
    public String, int, String, Color, String, String
    getStateInfo(String abbrev) {
    return name, population, stateFlower, stateColor,
    or, stateAnimal, governorsName;
    there no indication on what the return valuesrepresent.
    Well, I guees the API docs would have to speak for
    themselves. Or better method naming... In that
    sense, it's no different then now. I could write a
    method "getStateName()" and return totally different.
    public String, int getStateNameAndPopulation(String
    abbrev) {...
    I used to like "tuples" when I studied The Tom Programming Language (that's how he calls them), as every CS student is a bit of a "featurist"... Now that I came to develop 40 hours a week and to love Java's simple and powerful expressiveness, I tend to find such constructs overly ugly to be avoided as possible... a matter of personal taste, too, I suppose...

  • I want multiple return types, I think....

    I'm working on a system where I want a factory method that returns AWT Components that implement some interface X. I can't simply use an abstract class Y that extends component and implements X because the components that I want to have implement X subclass things like JLabels and JPanels. Furthermore, I don't really care about a type Y, as it would be meaningless in my system other than being the combination of these two types.
    This is a language issue because what I really want my function to look like is:
    public {Component, X} createXComponent(...) {
      return new (thing that is both Component and implements X);
    }where [Component, X] indicates the return type. Assuming that the abstract class is not an option, is there any way that I can design around this, and if not, might this sort of scenario possibly warrant a future langauge extension? It could come in the form of a type declaration that wasn't a class in itself, but indicated a named combination of 0 or 1 classes and some number of interfaces.
    Thoughts?
    Ben Kuhn

    I think the answer to my question at this point is
    that no, there's no convenient alternative design
    solution, and I've settled on using a sig. that
    returns X (and casting to component as needed), but I
    was looking for a more semantically correct solution.That seems like the best way to do it. When needed you can use the instanceof operator to see if the cast will be allowed.
    Another option may be to have your interface X include a method called
       public Component getComponent();The implementation in the concrete classes would be something like this:
       public Comonent getComponent() {
          return this;
       }Then if you wanted the Component view of the object you could call getComponent() rather than casting.
    Just a thought.

  • Multiple return values (Bug-ID 4222792)

    I had exactly the same request for the same 3 reasons: strong type safety and code correctness verification at compile-time, code readability and ease of mantenance, performance.
    Here is what Sun replied to me:
    Autoboxing and varargs are provided as part of
    JSRs 14 and 201
    http://jcp.org/en/jsr/detail?id=14
    http://jcp.org/en/jsr/detail?id=201
    See also:
    http://forum.java.sun.com/forum.jsp?forum=316
    http://developer.java.sun.com/developer/earlyAccess/adding_generics/index.html
    Multiple return values is covered by Bug-ID 4222792
    Typically this is done by returning an array.
    http://developer.java.sun.com/developer/bugParade/bugs/4222792.html
    That's exactly the problem: we dynamically create instances of array objects that would better fit well within the operand stack without stressing the garbage collector with temporary Array object instances (and with their backing store: 2 separate allocations that need to be recycled when it is clearly a pollution that the operand stack would clean up more efficiently)
    If you would like to engage in a discussion with the Java Language developers, the Generics forum would be a better place:
    http://forum.java.sun.com/forum.jsp?forum=316
    I know that (my report was already refering to the JSR for language extension) Generics is not what I was refering to (even if a generic could handle multiple return values, it would still be an allocated Object
    instance to pack them, i.e. just less convenient than using a static class for type safety.
    The most common case of multiple return values involve values that have known static datatypes and that should be checked with strong typesafety.
    The simple case that involves returning two ints then will require at least two object instances and will not solve the garbage collection overhead.
    Using a array of variable objects is exactly similar, except that it requires two instances for the components and one instance for the generic array container. Using extra method parameters with Integer, Byte, ... boxing objects is more efficient, but for now the only practical solution (which causes the least pollution in the VM allocator and garbage collector) is to use a custom class to store the return values in a single instance.
    This is not natural, and needlessly complexifies many interfaces.
    So to avoid this pollution, some solutions are used such as packing two ints into a long and returning a long, depacking the long after return (not quite clean but still much faster at run-time for methods that need to be used with high frequencies within the application. In some case, the only way to cut down the overhead is to inline methods within the caller code, and this does not help code maintenance by splitting the implementation into small methods (something that C++ can do very easily, both because it supports native types parameters by reference, and because it also supports inline methods).
    Finally, suppose we don't want to use tricky code, difficult to maintain, then we'll have to use boxing Object types to allow passing arguments by reference. Shamely boxed native types cannot be allocated on the operand stack as local variables, so we need to instanciate these local variables before call, and we loose the capacity to track the cases where these local variables are not really initialized by an effective call to the method that will assign them. This does not help debugging, and is against the concept of a strongly typed language like Java should be:
    Java makes lots of efforts to track uninitialized variables, but has no way to determine if an already instanciated Object instance refered in a local variable has effectively received an effective assignment because only the instanciation is kept. A typical code will then need to be written like this:
    Integer a = null;
    Integer b = null;
    if (some condition) {
    //call.method(a, b, 0, 1, "dummy input arg");
    // the method is supposed to have assigned a value to a and b,
    // but can't if a and b have not been instanciated, so we perform:
    call.method(a = new Integer(), b = new Integer(), 0, 1, "dummy input
    arg");
    // we must suppose that the method has modified (not initialized!)
    the value
    // of a and b instances.
    now.use(a.value(), b.value())
    // are we sure here that a and b have received a value????
    // the code may be detected at run-time (a null exception)
    // or completely undetected (the method() above was called but it
    // forgot to assign a value to its referenced objects a and b, in which
    // case we are calling in fact: now.use(0, 0); with the default values
    // or a and b, assigned when they were instanciated)
    Very tricky... Hard to debug. It would be much simpler if we just used:
    int a;
    int b;
    if (some condition) {
    (a, b) = call.method(0, 1, "dummy input arg");
    now.use(a, b);
    The compiler would immediately detect the case where a and b are in fact not always initialized (possible use bere initialization), and the first invoked call.method() would not have to check if its arguments are not null, it would not compile if it forgets to return two values in some code path...
    There's no need to provide extra boxing objects in the source as well as at run-time, and there's no stress added to the VM allocator or garbage collector simply because return values are only allocated on the perand stack by the caller, directly instanciated within the callee which MUST (checked at compile-time) create such instances by using the return statement to instanciate them, and the caller now just needs to use directly the variables which were referenced before call (here a and b). Clean and mean. And it allows strong typechecking as well (so this is a real help for programmers.
    Note that the signature of the method() above is:
    class call {
    (int, int) method(int, int, String) { ... }
    id est:
    class "call", member name "method", member type "(IILjava.lang.string;)II"
    This last signature means that the method can only be called by returning the value into a pair of variables of type int, or using the return value as a pair of actual arguments for another method call such as:
    call.method(call.method("dummy input arg"), "other dummy input arg")
    This is strongly typed and convenient to write and debug and very efficient at run-time...

    Can anyone give me some real-world examples where
    multiple return values aren't better captured in a
    class that logically groups those values? I can of
    course give hundreds of examples for why it's better
    to capture method arguments as multiple values instead
    of as one "logical object", but whenever I've hankered
    for multiple return values, I end up rethinking my
    strategy and rewriting my code to be better Object
    Oriented.I'd personally say you're usually right. There's almost always a O-O way of avoiding the situation.
    Sometimes though, you really do just want to return "two ints" from a function. There's no logical object you can think of to put them in. So you end up polluting the namespace:
    public class MyUsefulClass {
    public TwoInts calculateSomething(int a, int b, int c) {
    public static class TwoInts {
        //now, do I use two public int fields here, making it
        //in essence a struct?
       //or do I make my two ints private & final, which
       //requires a constructor & two getters?
      //and while I'm at it, is it worth implementing
      //equals(), how about hashCode()? clone()?
      //readResolve() ?
    }The answer to most of the questions for something as simple as "TwoInts" is usually "no: its not worth implementing those methods", but I still have to think about them.
    More to the point, the TwoInts class looks so ugly polluting the top level namespace like that, MyUsefulClass.TwoInts is public, that I don't think I've ever actually created that class. I always find some way to avoid it, even if the workaround is just as ugly.
    For myself, I'd like to see some simple pass-by-value "Tuple" type. My fear is it'd be abused as a way for lazy programmers to avoid creating objects when they should have a logical type for readability & maintainability.
    Anyone who has maintained code where someone has passed in all their arguments as (mutable!) Maps, Collections and/or Arrays and "returned" values by mutating those structures knows what a nightmare it can be. Which I suppose is an argument that cuts both ways: on the one hand you can say: "why add Tuples which would be another easy thing to abuse", on the other: "why not add Tuples, given Arrays and the Collections framework already allow bad programmers to produce unmainable mush. One more feature isn't going to make a difference either way".
    Ho hum.

  • Custom components that accept multiple data types

    The components that come with Flex, such as Datagrid, can
    accept
    multiple data types as a data source. For instance, you can
    bind a
    Datagrid to XML return from an HTTPService request or you can
    build an
    array and bind to that. I'd like to build my own component
    that does
    something similar, but I can't find any examples of this. I
    don't
    really even know what terms I'd search under to find it.
    Can anyone out there give me any idea of how this is done?
    Also, I'm a
    bit hazy on how the column definitions you set up in the MXML
    tag get
    received inside the class. I'd appreciate any insight on how
    this
    works.
    Thanks;
    Amy

    "Amy Blankenship *AdobeCommunityExpert*"
    <[email protected]>
    wrote in message news:[email protected]...
    >
    > "rvollmar" <[email protected]> wrote in
    message
    > news:[email protected]...
    >> For the second part of your post, are you asking how
    to set up columns in
    >> ActionScript? e.g.
    >>
    >> private function setColumnConfig1(dg:DataGrid):void{
    >> colArray = new Array();
    >> var col1:DataGridColumn = new DataGridColumn();
    >> var col2:DataGridColumn = new DataGridColumn();
    >> var col3:DataGridColumn = new DataGridColumn();
    >> var col4:DataGridColumn = new DataGridColumn();
    >> var col5:DataGridColumn = new DataGridColumn();
    >> var col6:DataGridColumn = new DataGridColumn();
    >>
    >> col1.dataField = "recordName";
    >> col2.dataField = "image";
    >> col3.dataField = "recordAmount";
    >> col4.dataField = "who";
    >> col5.dataField = "where";
    >> col6.dataField = "when";
    >>
    >> col2.itemRenderer = application.ImageRenderer;
    >>
    >> colArray.push(col1);
    >> colArray.push(col2);
    >> colArray.push(col3);
    >> colArray.push(col4);
    >> colArray.push(col5);
    >> colArray.push(col6);
    >>
    >> dg.columns = colArray;
    >> }
    >>
    >> Or were you wondering, when one writes this in mxml:
    >>
    >> <mx:columns>
    >> <mx:DataGridColumn ...>
    >> ...
    >> </mx:columns>
    >>
    >> how do you then have the control use that
    information?
    >
    > The latter. But the fact is that I was misreading the
    example I was
    > looking at.
    >
    > <?xml version="1.0"?>
    > <!-- dpcontrols/DataGridSimpleAttributes.mxml -->
    > <mx:Application xmlns:mx="
    http://www.adobe.com/2006/mxml">
    > <mx:DataGrid>
    > <mx:ArrayCollection>
    > <mx:Object Artist="Pavement"
    > Album="Slanted and Enchanted" Price="11.99" />
    > <mx:Object Artist="Pavement"
    > Album="Brighten the Corners" Price="11.99" />
    > </mx:ArrayCollection>
    > </mx:DataGrid>
    > </mx:Application>
    > I was thinking the ArrayCollection was going to the
    columns, but of course
    > it is the dataProvider. Am I right in thinking that
    internally the
    > control has a defaultProperty metatag that enables the
    contents of the
    > parent DataGrid tag to just come in and populate the
    dataProvider through
    > PFM?Thanks;Amy
    OK, I have looked at the source file, and it looks like the
    [DefaultProperty] metatdata tag is at least not used in the
    ListBase.as
    class. So I am guessing it is either higher or lower in the
    heirarchy...?
    -Amy

  • Should Collections be used as return types across threads?

    I am wondering when, if ever, it is appropriate to use a Collection as the return type of a method in a multi-threaded environment. Here is our situation:
    We have four classes -- Widget, WidgetManager, ClientA, and ClientB. ClientA and ClientB are running in different Threads from each other and from the WidgetManager.
    The WidgetManager class that uses a Collection of Widgets internally, and passes the Collection (or an Iterator over it) out as a return value of a method to ClientA, which is running in another thread. ClientA would start to go through it using next() and hasNext() of the Iterator. If the WidgetManager were to get a request from ClientB running in another thread to eliminate a Widget, it would attempt to remove it from the Collection. If ClientA were still looping through the Iterator, this would throw an IllegalStateException b/c the system would be in an inconsistent state. The Iterator given to the ClientA is directly linked to the actual Collection in the WidgetManager (am I right so far?).
    In my opinion, in most cases we don't want to synchronize Collections. In the example above, if we had passed out a synchronized Collection, then the WidgetManager couldn't touch the collection while the client was looping through the Iterator. If the client got hung up while looping, then the WidgetManager would be hung up. In this case, I think that it will be better to use the toArray() method of Collection to just dump out the contents to a plain array of Objects. Actually, the WidgetManager could convert this array of Objects to an array of Widgets before passing it out, which would give us the type checking that we don't get with Containers.
    The condition where you would want to use a synchronized Collection would be when you actually want the client to do some writing or removing from the Collection. I would expect this to be pretty rare since you usually dont want to give clients access to an interal member (the Collection) of a class.
    I think that it is also possible to have read-only Collections, but I think (don't know for sure) that you would still have the same IllegalStateException or synchronization probelms.
    Can someone point out the errors in my thinking? Or should you generally only use Collections as internal members in a multi-threaded environment, and use toArray() whenever you want to pass the Collection's data outside of the class?
    Thanks for any help.
    Keith

    I haven't tested what happens when you synchronize the
    Collection, but I think that you are right. But this
    causes the problem that I mentioned in the first post.
    That is, what happens if your client STARTS running
    through the Iterator, and then stops or gets hung up
    for some reason? I assume that you're still blocked.
    And it's pretty important to me in this case to not
    t be blocked -- WidgetManager is the highest level
    class in the system.
    I'd like to know if anyone has tested this.
    The Iterator implementations used in java.util do not use any synchronization by itself, (which is what you would expect since synchronization over multiple method call will involve much more complications and slower performance) . With iterator, you have to provide the necessary synchronization yourself to maintain thread-safety like this
    Iterator itr = get Iterator from collectionInstance ;
    synchronized(collectionInstance) {
    while(itr.hasNext())
    process itr.next() ...
    As long as your client code gracefully exits the synchronized block on a stop( or hangup, given that it is detected and handled fast enough), it will not be a problem.
    Also, I'd like an example of when you WOULD want to
    return a Collection. I'm specifically interested in
    when you would want to return one in a multi-threaded
    environment, but I'm beginning to wonder when you
    would EVER want to return one from a method.
    Collections are great for internal uses, but you lose
    type-checking and you expose the internals of your
    class to modification when you use them as return
    types. And if you're returning a read-only
    Collection, you might as well return an array, right?Using a read-only proxy will be much faster and space-efficient than toArray().

  • Two methods with same name but different return type?

    Can I have two methods with same name but different return type in Java? I used to do this in C++ (method overloading or function overloading)
    Here is my code:
    import java.io.*;
    public class Test{
    public static void main(String ar[]){
    try{          
    //I give an invalid file name to throw IO error.
    File file = new File("c:/invalid file name becasue of spaces");
    FileWriter writer = new FileWriter(file ,true);
    writer.write("Test");
    writer.close();     
    } catch (IOException IOe){
         System.out.println("Failure");
    //call first method - displays stack trace on screen
         showerr(NPe);
    //call second method - returns stack trace as string
            String msg = showerr(NPe);
            System.out.println(msg);
    } // end of main
    public static void showerr(Exception e){
         StringWriter sw = new StringWriter();
         PrintWriter pw = new PrintWriter(sw);
         e.printStackTrace(pw);
         try{
         pw.close();
         sw.close();
         catch (IOException IOe){
         IOe.printStackTrace();     
         String stackTrace = sw.toString();
         System.out.println("Null Ptr\n" +  stackTrace );
    }//end of first showerr
    public static String showerr(Exception e){
         StringWriter sw = new StringWriter();
         PrintWriter pw = new PrintWriter(sw);
         e.printStackTrace(pw);
         try{
         pw.close();
         sw.close();
         catch (IOException IOe){
         IOe.printStackTrace();     
         return sw.toString();
    }//end of second showerr
    } // end of class
    [\code]

    Overloading is when you have multiple methods that have the same name and the same return type but take different parameters. See example
    public class Overloader {
         public String buildError(Exception e){
              java.util.Date now = new java.util.Date() ;
              java.text.DateFormat format = java.text.DateFormat.getInstance() ;
              StringBuffer buffer = new StringBuffer() ;
              buffer.append(format.format(now))
                   .append( " : " )
                   .append( e.getClass().getName() )
                   .append( " : " )
                   .append( e.getMessage() ) ;
              return buffer.toString() ;
         public String buildError(String msg){
              java.util.Date now = new java.util.Date() ;
              java.text.DateFormat format = java.text.DateFormat.getInstance() ;
              StringBuffer buffer = new StringBuffer() ;
              buffer.append(format.format(now))
                   .append( " : " )
                   .append( msg ) ;
              return buffer.toString() ;
         public String buildErrors(int errCount){
              java.util.Date now = new java.util.Date() ;
              java.text.DateFormat format = java.text.DateFormat.getInstance() ;
              StringBuffer buffer = new StringBuffer() ;
              buffer.append(format.format(now))
                   .append( " : " )
                   .append( "There have been " )
                   .append( errCount )
                   .append( " errors encountered.")  ;
              return buffer.toString() ;
    }Make sense ???
    Regards,

  • Is there a way to end a method that has no return type?

    Without using an exception, as they are costly I am told, and without using may if then statements, is it possible to end a method if some criteria isn't met.
    example.
    public void doThis(){
      // the method relies on the state of some
      // other things.
      if(!someBoolean) endHere
      // then following is the rest of the method.
      // I'd like to be able to do this so that the "meat"
      // of the method is located under the conditions
      // that must be met.
    }... Any thoughts?
    Thank You

    No need to hide or commit ritual suicide, the "void" keyword could lead you to think that your method can't use the return statement. At least you wrote code to investigate and didn't spend 10 or 20 posts asking for verification. Be aware, some folk will tell you that there should be only one exit point from the method, often this is true. In large methods you can get lost in the execution path if there are multiple exit points. I think it's a judgement call.
    As for returning a bogus boolean, but, from a design point of view, if your method really doesn't have anything to return to its caller then the signature should reflect that with a return type of void (I know you are suggesting returning the bogus boolean for a different reason, and you've abandoned the idea anyway, I'm just being pedantic here)(indulge me). Returning a bogus boolean makes the class method more difficult to understand from a design and JavaDoc point of view because I, as the user of your method, will see it returing a boolean and expect to be able to use that value, and it might color my view of what the method does.
    Lee

  • How to add list of multiple file types to file type of file dialog box in LabVIEW

    How to add list of multiple file types to file type of file dialog box in LabVIEW?
    In file dialog box there is option to add only one file type,in the list,not by seperating commas,
    regards,
    Naresh.N

    Write the file types in pattern Input string, separated by a semicolon ;
    For example:  *.vi;*.doc;*.jpeg;*.xls
    This should return the set of files with matching extensions
    Message Edited by devchander on 09-10-2008 08:02 AM
    Message Edited by devchander on 09-10-2008 08:03 AM

  • Calculation formula userexit not working for multiple condition types

    Hi,
    we have a problem in the CRM ISA-B2B scenario where the custom user exit is only working for single condition type.
    but we need it for multiple condition types .
    the value of the subtotal is not being retrieved for multiple conditions. at a time only one condition value is being retrieved and shown in the webshop - shopping basket.
    for ex:
    we have scenario 1 where Y001 -Freight condition type is applicable for one customer.and Y002 is applicable for another customer.
    when we are trying to show the subtotal condition value in the webshop by using a single custom user exit in the pricing procedure it is only working for either of the above 2 customers depending on the VMC cache status.
    is there any problem if use the single user exit for both condition types?
    and if it needs to be differentiated how exactly we can do that with the same logic in the java class.
    Thanks in advance,
    PSR.

    Hi Arshi,
    below is the code:
    public class ZValFormula_ZZWI1 extends ValueFormulaAdapter {
         private static String zzwi = "ZZWI1";
         private static char  zzwiC = '@';
         private static UserexitLogger userexitlogger = new UserexitLogger(
         ZValFormula_ZZWI1.class);
         public BigDecimal overwriteConditionValue(IPricingItemUserExit item,
                   IPricingConditionUserExit condition) {
              ICurrencyValue val = condition.getConditionValue();
              userexitlogger.writeLogDebug( "value saved for " + zzwi + " (" + zzwiC + ") = "
                        + val.getValueAsString());
              item.setSubtotal( zzwiC, val.getValue());
              return val.getValue();
    hope this would give more idea to look at the problem.
    Thanks,
    PSR

  • Problem building schema for return type as custom object

    Hi i am invoking a web service through a partner link. But when i expand the invoke variables( in structure tab ), it shows Exception- Problem building schema.
    Response is of type java:Customer which is a custom object having mobile_no, name, compname.
    Error is--
    Invalid reference: 'java:customobjectproject:Customer'
    wsdl file:
    <?xml version='1.0' encoding='UTF-8'?>
    <definitions name="CustomerDetailServiceDefinitions" targetNamespace="http://customobjectproject" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:s0="http://customobjectproject" xmlns:s1="http://schemas.xmlsoap.org/wsdl/soap/">
    <types>
    <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://customobjectproject" xmlns:s0="http://customobjectproject" xmlns:s1="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="getCustomer">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="mobileNo" type="xs:int"/>
    <xs:element name="name" type="xs:string"/>
    <xs:element name="compName" type="xs:string"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    <xs:element name="getCustomerResponse">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="return" type="java:Customer" xmlns:java="java:customobjectproject"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    </xs:schema>
    <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="java:customobjectproject" xmlns:s0="http://customobjectproject" xmlns:s1="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:complexType name="Customer">
    <xs:sequence>
    <xs:element minOccurs="1" name="Mobile_no" nillable="false" type="xs:int"/>
    <xs:element minOccurs="1" name="Name" nillable="true" type="xs:string"/>
    <xs:element minOccurs="1" name="CompName" nillable="true" type="xs:string"/>
    </xs:sequence>
    </xs:complexType>
    </xs:schema>
    </types>
    <message name="getCustomer">
    <part element="s0:getCustomer" name="parameters"/>
    </message>
    <message name="getCustomerResponse">
    <part element="s0:getCustomerResponse" name="parameters"/>
    </message>
    <portType name="CustomerDetail">
    <operation name="getCustomer" parameterOrder="parameters">
    <input message="s0:getCustomer"/>
    <output message="s0:getCustomerResponse"/>
    </operation>
    </portType>
    <binding name="CustomerDetailServiceSoapBinding" type="s0:CustomerDetail">
    <s1:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="getCustomer">
    <s1:operation soapAction="" style="document"/>
    <input>
    <s1:body parts="parameters" use="literal"/>
    </input>
    <output>
    <s1:body parts="parameters" use="literal"/>
    </output>
    </operation>
    </binding>
    <service name="CustomerDetailService">
    <port binding="s0:CustomerDetailServiceSoapBinding" name="CustomerDetailSoapPort">
    <s1:address location="http://localhost:7030/CustomerDetail/CustomerDetail"/>
    </port>
    </service>
    </definitions>
    I am using jdeveloper 10.1.3.3.0. Please help..
    Thanks.

    Well, the problem is caused by the fact that BPEL does not yet support soapenc:Array types. We've created a workaround by defining two Services, one that has only single returntypes and one that has the multiple returntypes (which are defined using soapenc:Array). There are other solutions, but those are very complicated. Hope this helps!

  • Overloading hassle with no args, different return types

    We're trying to create a document object that can be parsed from XML with xerces and then used as the model for a jtree and a styled-text editor. That means we want to:
    1. subclass stuff from org.w3c.dom
    2. implement interfaces from javax.swing.tree
    3. implement interfaces from javax.swing.text
    We figured that since they all represent similar tree structures, this would be a nice and clever thing to do.
    Hit a snag this morning:
    * org.w3c.dom.Node.getAttributes() returns NamedNodeMap
    * javax.swing.text.Element.getAttributes() returns AttributeSet
    So, our class gets a compile error on the conflicting return types for what it thinks is the same method.
    Any suggestions for what to do? Abandoning xerces isn't an option, and rewriting styled text ourselves isn't practial either.
    --Chris (invalidname)

    This is the problem with multiple inheritance. In C++, the problem is more pronounced because you can inherit two implmentations of the same method.
    In Java, whenever you inherit two methods with the same signature, even if the return types are the same, you have a similar problem. These two methods will likely have two different contracts, and you cannot fulfuill both contracts with one method.
    Example:
    interface Graphical { /** Draw object on screen */ void draw() { } }
    interface CardDeck { /** Draw a card */ void draw() { } }
    class CardGame implements Graphical, CardDeck { /** ??? */ void draw() { } }It is unfortunate that you're inheriting two different getAttributes() methods. You'll have to use composition and delegation instead of inheritance to get around the problem.

  • Changing Multiple Linked Type Layers

    Changing Multiple Linked Type Layers
    If you want to make the same change to more than one Type Layer at the same
    time, just link all of the Layers you want effected in the Layers palette,
    then hold the Shift key and make your changes to one of the Linked Layers.
    All of the Linked Layers will show the same change.

    Hi Jeff,
    I'm beginning to develop a strong dislike for this forum's new interface!!
    But that's not your fault.
    The tables below use a VLOOKUP formula to retrieve the prices from the Current Pricing, and an IF statement in E1 to determine which column the prices are fetched from.
    The added column isn't necessary; it was just simpler t do that than to go through the hassle of re-merging the single cell in Row 1. With a change of the cell reference in the VLOOKUP formula, the first formula can be placed anywhere convenient.
    In E1:
    =IF(LEFT(A1,1)="I",2,3)
    The result of this formula tells VLOOKUP to return the results from column 2 or 3 of the Current Pricing table, depending on the first letter of the text in A1 being an "I".
    In C3 and Filled Down:
    =IF(B>0,VLOOKUP(A,Current Pricing :: $A:$C,$E$1,FALSE),"")
    IF is used to return a null string unless there is a value greater than zero in column B.
    Looks for the item listed in Column A and returns the value from the row where that item is found and the column specified in E1.
    The error triangle in C9 is a "VLOOKUP cannot find.." error cause by the value '3” screws (25lb box)' not being found in column A of Current Pricing.
    The error triangle in D9 is "There is an error in C9".
    Regard,
    Barry
    PS: The line at the beginning?
    I had complete all but the last line of a previous version of this post, and was deleting the '3" screws..." bit which had pasted as a single cell unnamed table, when the software bumped me back to the previous thread in this community. Not the first time this has happened, and in this case, as in the ones before, there appeared to be no route back to my partly completed message. So it was start over time. (/rant)
    B

  • With Pages 5.2 how can i use multiple language types in a single document

    My Macbook Air Has the version 10.9.3
    I'm used to work with the old version of Page.
    But now I am using the new version of Pages 5.2 (1860).
    I want to know with the new version how do I use an multiple language types in a single document option.
    In the old  version of Pages I was using  Inspector -> Text -> "More" tab -> Language: British Inglese.
    In the new Pages 5.2 I do not know how to do it
    Could you help me?
    melo

    It's not possible to tag text with multiple languages in Pages 5.  Go back to Pages 4, which should still be in you iWork folder.
    For the whole doc in Pages 5, use Edit > Spellling and Grammar > Show Spelling and Grammar.

Maybe you are looking for