Actually I found a cheap workaround.

In my Tapestry Service Implementation class constructor, do a jndi lookup
for the session/business layer interface.  I might switch back to my master
branch now :)



    public TapestryUserServiceImpl() {
        try {
            _initialContext = new InitialContext();
            String jndiName = "java:global/" + Version.EARMOD + "-" +
Version.VERSION + "/" + Version.EJBMOD + "-" + Version.VERSION + "/" +
"SubnetsUserFacade";
            userService = (SubnetsUserFacadeLocal)
_initialContext.lookup(jndiName);
        } catch (NamingException e) {
            e.printStackTrace();
        }
    }



On Wed, Sep 17, 2014 at 8:48 AM, Chris Mylonas <ch...@opencsta.org> wrote:

> Brilliant, thanks Thiago.  I'm spending a month doing mainly tapestry
> stuff luckily and will put some workflow R&D in.
>
> I have nonetheless created a branch in my project doing the monkey
> business of manual transformation because I'm deadlining on multiple
> projects and will go with proven tech.
> On 16/09/2014 11:02 pm, "Thiago H de Paula Figueiredo" <thiag...@gmail.com>
> wrote:
>
>> On Tue, 16 Sep 2014 06:06:55 -0300, Chris Mylonas <ch...@opencsta.org>
>> wrote:
>>
>>  Hi Tapestry Users,
>>>
>>
>> Hi!
>>
>>  Is there a limitation to how/where to use @EJB?
>>>
>>
>> It depends on how your project handles it.
>>
>>  All my tapestry services
>>> and their implementation are in the services package - is this one of
>>> those special packages I should move my services out of?
>>>
>>
>> No. The services package doesn't have any special meaning for Tapestry
>> except for the default location of AppModule.
>>
>>  AppModule.java has
>>>     @Primary
>>>     public static void contributeComponentClassTransformWorker(
>>>             OrderedConfiguration<ComponentClassTransformWorker2>
>>> configuration) {
>>>         configuration.addInstance("EJB", EJBAnnotationWorker.class,
>>> "before:Property");
>>>     }
>>>
>>
>> ComponentClassTransformWorker, as its name says, changes component (and
>> pages and mixins) classes, not service ones (or any other class).
>>
>> If you want an annotation to work on services, which are actually a
>> Tapestry-IoC concept, not a Tapestry(-core) one (Tapestry-Core uses
>> Tapestry-IoC services), you should do it in Tapestry-IoC.
>>
>> Have you tried https://github.com/got5/tapestry-cdi?
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>

Reply via email to