peter coster

Greenhorn
+ Follow
since Jan 13, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by peter coster

Hi,

I have to write a WS client for an application which name I won't mention, but that isn't exactly providing valid webservices.

I have to use a ****.dll?SOAP as the endpoint. There is no WSDL, so I've build one myself. Now that I try to test it I see that this application requires specific namespace prefixes:



What I mean is that I have to use the company name as the prefix for what you can see as . And that I have to use SOAP-ENV as prefix for the soap namespace. The problem is that the soap request that is generated by jaxws uses the more common lowercase soapenv prefix and uses n0 for the prefix in the message
I fail to find a way to do this in JAXWS. I have found a NamespacePrefixMapper in JAXB, but can't see how to invoke this from JAXWS (more specifically the JAXWS-MAVEN plugin.

I am using the latest version of both JAXWS and JAXB
[ November 12, 2008: Message edited by: peter coster ]
16 years ago
Mike,

Like I said, this was just a quick test for me. So I certainly wouldn't use the word bug.
But these are a few things:

  • I used auto schema creation - this caused warnings for sequences that already existed, hibernate does it different.
  • the combination of OneToMany and a joinColumn was not allowed, I tought this was legal ? Haven't tried it with hibernate.


  • This experience and comments from colleagues who had started projects with Toplink but switched to Hibernate because of problems (don't know what specifically), made me switch. More to have a quick result then for anything else really.
    Mike,

    It works now, and looking at it now it does seem very logic, I can't believe that I didn't see this earlier, lesson learned, thanks.

    However I did find other things working less well on toplink essentials, which is a shame as I really like Glassfish.
    This is the patient code - meanwhile with the manytoone relationship:



    I've also added to the onetomany annotation in the medic class.

    what happens now is that the manytoneone side works and medicIds are stored in the patient table (so no jointable, just a joincolumn ) medic.Getpatients has no result..

    I don't understand....
    Shailesh,

    Thank you for the reply. I'm using schema generation. And the jointable is automatically generated. So the JPA provider does now about it. It just doesn't seem to understand that it needs to persist the relation.

    However, I did try to do your suggestion and make it bidirectional, even adding patient.setMedic(mergedMedic); explicitly to the code. But this didn't change the outcome.
    I'm trying out some basic stuff with EJB3/JPA. Using glassfish V2 and first Toplink then Hibernate (does seem to work better).

    I've made what I think is the most basic example possible, but somehow it doesn't work:

    I'll post the code here, only the relevant bits:

    I have a Medic entity:



    And a Patient entity which has no relations (the oneToMany is unidirectional) and only an @Id / @GeneratedValue annotation (same as medic)

    Then I have a SLSB:



    Now when I create a Medic and then call this createPatient a few times the following happens:

    Using Toplink => patients are created and assigned correct Ids, but the jointable (which is also correctly created) remains empty.

    In Hibernate the same thing happens, but there the last patient / medic combo is found in the MEDIC_PATIENT table. But if I then call Medic.getPatients().size() it still says 0.

    I'm sure I just did something stupid, but I just can't see what.
    I don't want to spam this topic, but I've found another possible solution -

    Currently the webapp has the following in its jboss-web.xml file:

    <class-loading>
    <loader-repository>
    myapp.com:loader=myapp.war
    </loader-repository>
    </class-loading>



    when I remove this, the application works with the multiple Qnames, problem is that off course this loader-repository option is put there for a reason - the application is installed in production together with a much older ear. Withouth the above everything explodes...
    Removing the javax.xml.namespace package from the stax-api.jar and from the xbean.jar "solves" the problem. Off course that is not a real solution.

    This was a bug:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6402423

    somehow it got closed, but I don't understand why ?

    PS: am I posting in the correct thread?
    This is the stacktrace:

    java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class
    at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:779)
    at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:25)
    at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:78)
    at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:41)
    at com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:97)
    at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:44)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:320)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:198)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:368)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)


    Google told us that this is because of the fact that different packages (xbeans-2.2, jsr172, axis1.3) all contain this javax/xml/namespace/QName class, as does java5. Knowing that I don't really now how I can solve this. Also, I really really don't understand why I seem to be the only one having this problem.

    The project is a war project running solo, the error occurs when invoking JAXB, not before. Which is strange I think as Xfire is used for logging in


    Thank you in advance.
    Since this means you would have 2 different JVM's I would think there is no 'java way' of doing this.

    First method that pops in my mind is using a "LOCK" file, on which your program holds on to while it's running. If it's not free when your program starts, it will terminate itself. But I'm pretty shure there are better ways for this.
    18 years ago
    You can do this using XSL-FO , using the apache fop engine.

    XML-Spy can also do this for you. (altova StyleVision)
    We currently have an application that uses opensaml to produce SAML assertions that are sent to an external app. using the browser/post model. We need to extend this application by adding a "login level" to the SAML message.
    The easiest way to do this is to add this to the SAMLAttributes, but I've been told that this is not the right way to do this. But what is the right way, is something that I haven't been able to find out.

    Does anyone has experience with this?

    Originally posted by Mr. C Lamont Gilbert:


    A SoftReference cleans itself. Thats its whole purpose. There is a whole package 'java.lang.ref' for this type of stuff. Yet you use JMX. Its the proverbial axe to swat a fly from a friends forehead.

    A soft reference will clean up its referrent when memory gets low, automatically. You do need to manage cleaning up the soft reference itself.

    Also I think i mentioned that GC is tuneable and in turn it makes your cache tuneable.

    [ June 10, 2006: Message edited by: Mr. C Lamont Gilbert ]



    I use JMX to clean that referenceQueue, and to keep my cache sync. with that Queue.

    What you suggested 2 posts back, is actually what we've been doing from the start. We did have one problem with it, when we started testing, which is that with the JVM set to client, Softreferences are cleaned to fast. Anyway, The thing works nice and fast now, so thank you all for the input.
    [ June 23, 2006: Message edited by: peter coster ]
    18 years ago
    The equals is also corrected now, we are using softreferences, JMX is only used to trigger the cleanup of these softreferences.
    18 years ago