welcome to the club, Laird :)
everyone is doing the same and everyone rollback to some copy point
after few trials.. let's wait for the advent of the Sandoz solution...
and then we can start to cleanup again..
:)
On Tue, Sep 1, 2009 at 7:55 PM, ljnelson<ljnelson_at_gmail.com> wrote:
> On Tue, Sep 1, 2009 at 1:15 PM, Paul Sandoz (via Nabble) <[hidden email]>
> wrote:
>>
>> I will implement support for a type T, but types like T[], Collection<T>
>> and Map<T, Collection<V>> are harder to resolve because it is difficulty
>> creating the concrete parameterized type definitions. If anybody knows of
>> any mechanism to help aid this i am all ears!
>
> OK, good to know.
>
>>
>> Background: I was hoping to put together a generic DAO that could return
>> collections of things without having to create a new resource for every
>> object that I wanted DAO functionality for.
>>
>> We need more samples :-) or those samples could be modified f appropriate.
>> Issues/patches/contributions welcome!
>
> Also good to know.
>
> I'd like to clarify my use case in case it helps, or in case by some chance
> it actually is handled. My use case is of course absolutely brain-dead
> simple for a Java EE application sitting on top of JPA.
>
> Right now I have a generic DAO roughly like this (again, typed off the cuff
> and with lots omitted for brevity):
>
> @Stateless
> public class AbstractDAO<T, P> {
>
> @PersistenceContext(/*...*/)
> private EntityManager em;
>
> public T find(P primaryKey) {
> return em.find(primaryKey);
> }
>
> }
>
> I'd like to add a method that, for example, runs a named query and returns
> the results:
>
> public List<T> findBySomeCriteria(/* criteria don't matter for this example
> */) {
> // make the appropriate named query here
> return (List<T>)query.getResultList(); // or whatever the call is; can't
> remember offhand
> }
>
> And I have in mind that somehow {handwave, handwave} the returned XML would
> as magically as possible be correct (suppose T evaluates to Foobar):
>
> <foobars>
> <foobar>First result item</foobar>
> <foobar>Second result item</foobar>
> </foobars>
>
> Now, as it happens, I have to subclass the DAO anyway for each type of
> object. This is in part so that the EJB interface it's called through
> correctly reflects the right type. That is, I would have to create a class:
>
> public class FoobarDAO extends AbstractDAO<Foobar, FoobarPrimaryKeyClass> {
> /* ... */ }
>
> Is it possible that if THIS class were invoked I would get back the proper
> XML from its findBySomeCriteria method?
>
> I am sorry--really, I am--for asking such braindead questions, but they are
> the first things that my colleague and I ran up against, and we didn't find
> an easy entry path towards the solution in the documentation. I am totally
> open to being redirected. :-)
>
> Best,
> Laird
>
> ________________________________
> View this message in context: Re: [Jersey] Spell out generics limitations?
> Sent from the Jersey mailing list archive at Nabble.com.
>
--
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/footprint-service/wadl