Skip to main content

JAX RS 2.0 Rest Services - Nested Objects are not marshaling correctly after migrating to GF4

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
7 replies [Last post]
scarfacevn
Offline
Joined: 2010-01-25

JAX-RS Project developed in NetBeans worked fine in Glassfish Server 3.x .But after migrated to Glassfish server 4.0, NESTED Transfer Objects are that are marshalled to JSON are not working correctly anymore. The "payload" element below should have been marshalled into JSON but instead translates to a mere "java pointer representation". It appears I might be missing a configuration or something related to Jersey 2.0/GF 4. Any help will be greatly appreciated!

JSON Response To Client

{
    code = 200;
    message = "Operation Succeeded";
    payload = "com.dcloud.rest.transfer.LoginResponseTO@788391df";
    status = OK;
}

Rest Method Annotation

    @POST
    @Path("/login")
    @Produces(MediaType.APPLICATION_JSON)
    public ResponseTO login(...) {
       ....
    }

web.xml Snippet

 <servlet>
        <description>Servlet for REST Services</description>
        <servlet-name>ServletAdaptor</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
       
        <init-param>
            <param-name>jersey.config.server.provider.packages</param-name>
            <param-value>com.dcloud.rest</param-value>
        </init-param>
       
        <security-role-ref>
            <description/>
            <role-name>user</role-name>
            <role-link>user</role-link>
        </security-role-ref>             
    </servlet>
    <servlet-mapping>
        <servlet-name>ServletAdaptor</servlet-name>
        <url-pattern>/rs/*</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
scarfacevn
Offline
Joined: 2010-01-25

Follow up:
I turned targeted logging for package org.glassfish.jersey in Glassfish 4.0 and see a bunch of exception messages.

FINEST:   A new abstract resource created by IntrospectionModeler: org.glassfish.jersey.server.model.Resource$Builder@55f181a4
FINER:   Unable to get the com.sun.proxy.$Proxy147 annotation value property
java.lang.NoSuchMethodException: javax.ejb.EJB.value()

What am I missing? Any help or pointers will be very much appreciated.

mgainty
Offline
Joined: 2004-05-21

a quick perusal of javadocs answers your question about use of value for implementors of EJB interface

@Retention(value=RUNTIME)

public @interface EJB
Indicates a dependency on the local, no-interface, or remote view of an
Enterprise JavaBean.
Either the beanName OR the lookup element can be
used to resolve the EJB dependency to its target session bean component.

It is
an error to specify values for both beanName and
lookup.

I pulled down the latest implementation of JSR311 spec from
http://grepcode.com/snapshot/repo1.maven.org/maven2/javax.ws.rs/jsr311-a...

and I cannot find use of EJB anywhere

which version of Axis are you using for your REST Service?

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

> To: users@glassfish.java.net
> Subject: Re: JAX RS 2.0 Rest Services - Nested Objects are not ...
> From: forums@java.net
> Date: Fri, 28 Jun 2013 09:44:21 -0500
>
> Follow up: I turned targeted logging for package org.glassfish.jersey in
> Glassfish 4.0 and see a bunch of exception messages. FINEST: A new abstract
> resource created by IntrospectionModeler:
> org.glassfish.jersey.server.model.Resource$Builder@55f181a4 FINER: Unable to
> get the com.sun.proxy.$Proxy147 annotation value property
> java.lang.NoSuchMethodException: javax.ejb.EJB.value() What am I missing? Any
> help or pointers will be very much appreciated.
>
> --
>
> [Message sent by forum member 'scarfacevn']
>
> View Post: http://forums.java.net/node/897514
>
>

scarfacevn
Offline
Joined: 2010-01-25

Thanks for posting a response. Not using Axis.
Using Glassfish 4 with Jersey 2.0-0.2. EJB3 with JAX-RS annotations

emailnbw
Offline
Joined: 2008-05-28

If an EJB method with a TX attribute of REQUIRES_NEW is invoked and it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED the container is supposed to suspend the association of the tx context with the current thread before invoking the NOT_SUPPORTED method.

My question is if the NOT_SUPPORTED method takes longer then the JDBC Connection Pool's "Connection Leak Timeout" will it get tripped or does this timeout not apply while a TX context is suspended?

I hope for the later but I suspect the former. Can anyone clarify. This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.

Thanks,

-Noah

mvatkina
Offline
Joined: 2005-04-04

I don't think the resource manager or transaction manager stop the
clocks when transaction is suspended.

-marina

On 6/28/13 2:20 PM, Noah White wrote:
> If an EJB method with a TX attribute of REQUIRES_NEW is invoked and it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED the container is supposed to suspend the association of the tx context with the current thread before invoking the NOT_SUPPORTED method.
>
> My question is if the NOT_SUPPORTED method takes longer then the JDBC Connection Pool's "Connection Leak Timeout" will it get tripped or does this timeout not apply while a TX context is suspended?
>
> I hope for the later but I suspect the former. Can anyone clarify. This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.
>
> Thanks,
>
> -Noah
>

ss141213
Offline
Joined: 2005-03-30

How can the connection which is still associated with a valid
transaction be categorised as a leaked connection?I also expect the same
behavior expected by Noah.

Thanks,
Sahoo
On Saturday 29 June 2013 03:00 AM, Marina Vatkina wrote:
> I don't think the resource manager or transaction manager stop the
> clocks when transaction is suspended.
>
> -marina
>
> On 6/28/13 2:20 PM, Noah White wrote:
>> If an EJB method with a TX attribute of REQUIRES_NEW is invoked and
>> it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED
>> the container is supposed to suspend the association of the tx
>> context with the current thread before invoking the NOT_SUPPORTED
>> method.
>>
>> My question is if the NOT_SUPPORTED method takes longer then the JDBC
>> Connection Pool's "Connection Leak Timeout" will it get tripped or
>> does this timeout not apply while a TX context is suspended?
>>
>> I hope for the later but I suspect the former. Can anyone clarify.
>> This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.
>>
>> Thanks,
>>
>> -Noah
>>
>

emailnbw
Offline
Joined: 2008-05-28

Sahoo,

I think the only way to affect the behavior I would like is to put the NOT_SUPPORTED logic in an @Asynchronous method that the REQUIRES_NEW calls. However, the introduction of the async thread to the code path has its own ramifications with respect to the state of the system.

I guess this comes down to the definition of a 'connection leak'. Is it simply a connection which has been open for a period of time longer then the leak timeout value regardless of the presence of traffic across it during that time and regardless of the state of the transaction context (suspended etc.)? Or is it more nuanced? To me it would make sense for it to take into account the state of the context and pause the timer since the context is being explicitly driven/set by the application logic.

-Noah

On Jun 30, 2013, at 2:09 AM, Sahoo wrote:

> How can the connection which is still associated with a valid transaction be categorised as a leaked connection?I also expect the same behavior expected by Noah.
>
> Thanks,
> Sahoo
> On Saturday 29 June 2013 03:00 AM, Marina Vatkina wrote:
>> I don't think the resource manager or transaction manager stop the clocks when transaction is suspended.
>>
>> -marina
>>
>> On 6/28/13 2:20 PM, Noah White wrote:
>>> If an EJB method with a TX attribute of REQUIRES_NEW is invoked and it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED the container is supposed to suspend the association of the tx context with the current thread before invoking the NOT_SUPPORTED method.
>>>
>>> My question is if the NOT_SUPPORTED method takes longer then the JDBC Connection Pool's "Connection Leak Timeout" will it get tripped or does this timeout not apply while a TX context is suspended?
>>>
>>> I hope for the later but I suspect the former. Can anyone clarify. This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.
>>>
>>> Thanks,
>>>
>>> -Noah
>>>
>>
>

tecknobabble
Offline
Joined: 2005-06-10

On 30/06/2013 18:06, Noah White wrote:
> Sahoo,
>
> I think the only way to affect the behavior I would like is to put the NOT_SUPPORTED logic in an @Asynchronous method that the REQUIRES_NEW calls. However, the introduction of the async thread to the code path has its own ramifications with respect to the state of the system.
>
> I guess this comes down to the definition of a 'connection leak'. Is it simply a connection which has been open for a period of time longer then the leak timeout value regardless of the presence of traffic across it during that time and regardless of the state of the transaction context (suspended etc.)?
I believe its the former. It is a simple timer that is started when a
connection is returned to the application, which will trigger when the
leak timeout period has passed. From a support perspective we'd
normally only suggest enabling the leak timeout when the pool keeps
running out of free connections and the max wait time is exceeded. That
simply provides a report in the log file with the call stack of the
thread that obtained the connection to allow someone to try to figure
out if there is an error in the connection handling logic in the
application, which unfortunately is the most common cause of leaks.

Enabling the leak reclaim option to then destroy the connection is an
option to attempt to provide relief until the application code is
corrected, but I've seen it cause problems, especially when the leak
timeout has been set too low and the connection is being actively used,
and its locked by the driver.
> Or is it more nuanced? To me it would make sense for it to take into account the state of the context and pause the timer since the context is being explicitly driven/set by the application logic.
>
> -Noah
>
>
> On Jun 30, 2013, at 2:09 AM, Sahoo wrote:
>
>> How can the connection which is still associated with a valid transaction be categorised as a leaked connection?I also expect the same behavior expected by Noah.
>>
>> Thanks,
>> Sahoo
>> On Saturday 29 June 2013 03:00 AM, Marina Vatkina wrote:
>>> I don't think the resource manager or transaction manager stop the clocks when transaction is suspended.
>>>
>>> -marina
>>>
>>> On 6/28/13 2:20 PM, Noah White wrote:
>>>> If an EJB method with a TX attribute of REQUIRES_NEW is invoked and it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED the container is supposed to suspend the association of the tx context with the current thread before invoking the NOT_SUPPORTED method.
>>>>
>>>> My question is if the NOT_SUPPORTED method takes longer then the JDBC Connection Pool's "Connection Leak Timeout" will it get tripped or does this timeout not apply while a TX context is suspended?
>>>>
>>>> I hope for the later but I suspect the former. Can anyone clarify. This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.
>>>>
>>>> Thanks,
>>>>
>>>> -Noah
>>>>

--
Oracle
Oracle Customer Services | GlassFish & Coherence Support
Steve Essery | Senior Principal Support Consultant
Phone: +44 1189 249508 | Mobile: +44 7748
112165
TVP 540, Oracle Parkway, Thames Valley Park, Reading, RG6 1RA, United
Kingdom

ORACLE Corporation UK Ltd is a company incorporated in England & Wales |
Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley
Park, Reading RG6 1RA
Green Oracle Oracle is committed to
developing practices and products that help protect the environment