Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-14 Thread Lenny Primak
While it is true that you can put Tapestry library in the shared classloader (I 
do it in the development environment)
and you can share the registry, you still can't call from one webapp into 
another,
as the services themselves will still be loaded by different classloaders and 
cannot be shared.

On Dec 14, 2012, at 3:31 AM, Lance Java wrote:

>> You cannot use approach #2. Two separate web apps cannot call each other
> directly.
>> This is like having two processes on separate machines in separate JVMs. 
> 
> This is not entirely true. As Josh said there is a classloader which is
> common to all webapps running in a container. Take a look at the classloader
> hierarchy here:
> http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html.
> 
> I agree with Josh that if you put your jars in the shared lib folder
> (instead of mywebapp/WEB-INF/lib) you might be able to share the registry.
> I'm just not sure if it's a good idea ;)
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686p5718716.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-14 Thread Lenny Primak
EJB3 is great. Don't hesitate to use it. 

On Dec 14, 2012, at 8:12 AM, Martin Nagl  wrote:

> Putting tapestry jars in shared folder to have them loaded by common class
> loader seems not quite right to me. Its a hack :) My high level feeling is:
> 
> 1. Tapestry can provide IOC and JPA support in scope of 1 web application. 
> 2. If I need IOC and JPA (and EJB) support in scope of multiple web
> applications, I need to delegate this to full application server (e.g.
> Glassfish, TomEE, etc). 
> 
> Looks like I can not avoid EJB if I want multiple WARs to share services.
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686p5718720.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-14 Thread Lance Java
You could extract your shared services into a separate war and expose them as
web-services.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686p5718721.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-14 Thread Martin Nagl
Putting tapestry jars in shared folder to have them loaded by common class
loader seems not quite right to me. Its a hack :) My high level feeling is:

1. Tapestry can provide IOC and JPA support in scope of 1 web application. 
2. If I need IOC and JPA (and EJB) support in scope of multiple web
applications, I need to delegate this to full application server (e.g.
Glassfish, TomEE, etc). 

Looks like I can not avoid EJB if I want multiple WARs to share services.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686p5718720.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-14 Thread Lance Java
> You cannot use approach #2. Two separate web apps cannot call each other
directly.
> This is like having two processes on separate machines in separate JVMs. 

This is not entirely true. As Josh said there is a classloader which is
common to all webapps running in a container. Take a look at the classloader
hierarchy here:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html.

I agree with Josh that if you put your jars in the shared lib folder
(instead of mywebapp/WEB-INF/lib) you might be able to share the registry.
I'm just not sure if it's a good idea ;)






--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686p5718716.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-13 Thread Lenny Primak
You cannot use approach #2. Two separate web apps cannot call each other 
directly. 
This is like having two processes on separate machines in separate JVMs. 
The only way they can communicate is through remote calls I.e. RPC rest or web 
services. 

On Dec 13, 2012, at 12:54 PM, Martin Nagl  wrote:

> Hi all, 
> 
> I am considering my options for building a combo of T5 web application +
> Jersey REST interface for this application. I am thinking about:
> 
> Step 1: Implementing a T5 application with my business logic (DB access,
> computations) placed in Tapestry IOC services, because I like how the IOC
> and JPA support plays together out-of-the-box.   
> Step 2: Implementing a Jersey web aplication which will reuse my Tapestry
> IOC services and expose the REST interface
> 
> I tried 2 approaches. Approach 1 works, approach 2 fails (I think I am
> missing somethig basic here). 
> 
> Approach 1: Everything in one WAR, share Registry via ServletContext:   
> - /myapp/web/
> - /myapp/rest/ 
> - Make Tapestry 5 application run in folder "web", by providing
> configuration SymbolConstants.APPLICATION_FOLDER in AppModule
> - In web.xml: map the TapestryFilter to /web/*, 
> - In web.xml: add a Jersey Servlet and map it to /rest/*
> - In Jersey resource: access the Registry instance stored in ServletContext
> and access my service like this:
>   Registry registry =
> (Registry)context.getAttribute(TapestryFilter.REGISTRY_CONTEXT_NAME);
>   EmployeeService service = registry.getService(EmployeeService.class);
> 
> Approach 1 works, because TapestryFilter and JerseyServlet share the
> ServletContext (are part of same webapp). However, I would like to have
> separate WARs for the Jersey and for the T5 app. I may need this to
> configure different auth-method in  in web.xml for Jersey app
> than for T5 app.
> 
> Approach 2: Separate WARs, share Registry via JNDI.  
> - /myapp-web/
> - /myapp-rest/  
> - In T5 app, after Registry startup, store the Registry instance in JNDI
> somehow
>  InitialContext ic = new InitialContext();
>ic.rebind("java:registry", registry);
> - In Jersey app, access the Registry through JNDI and access my service:
>  InitialContext ic = new InitialContext();
>Object object = ic.lookup("java:registry");
>Registry registry = (Registry)object; 
>EmployeeService service = registry.getService(EmployeeService.class);
>
> Approach 2 fails with ClassCastException in this line:
> Registry registry = (Registry)object;
> ClassCastException: org.apache.tapestry5.ioc.internal.RegistryWrapper
> cannot be cast to org.apache.tapestry5.ioc.Registry. 
> 
> I am using Jetty. I debuged it and found that object from lookup() has a
> class from a different classloader than class I cast it to, because they
> come from different contexts (each context has a separate classloader). I
> have little experience with storing objects in JNDI, I think I am missing
> something basic here, maybe JNDI is not even meant to be used like this
> Is it even feasible to share Registry through JNDI?
> 
> Please share your thoughts, is there any other way to share my the Tapestry
> IOC Service from running T5 app to another web application, deployed in the
> same container? Is this even a good idea? Or should I keep all in 1 WAR?
> 
> For the record, I also considered: business logic in a separate EJB layer,
> shared by both apps, both apps deployed to Glassfish. This environment is
> somewhat hard to configure for me, for example because tapestry-jpa
> conflicts with AS-managed persistence context. I would like to keep the dev
> environment simple and make use of live class reloading. I use Eclipse +
> maven + jetty. 
> Thanks for any ideas.
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



Re: Sharing the Registry instance between web applications (deployed in the same container)

2012-12-13 Thread Josh Canfield
You're running into a problem with with the way classloaders work in an
application server. You might be able to make this work by putting the
tapestry jars + dependencies in the shared lib for jetty, they would then
be loaded from the same classloader. I haven't tried this and I'm not sure
it's going to work, but it's where I would start.

http://docs.codehaus.org/display/JETTY/Classloading

On Thu, Dec 13, 2012 at 9:54 AM, Martin Nagl  wrote:

> Hi all,
>
> I am considering my options for building a combo of T5 web application +
> Jersey REST interface for this application. I am thinking about:
>
> Step 1: Implementing a T5 application with my business logic (DB access,
> computations) placed in Tapestry IOC services, because I like how the IOC
> and JPA support plays together out-of-the-box.
> Step 2: Implementing a Jersey web aplication which will reuse my Tapestry
> IOC services and expose the REST interface
>
> I tried 2 approaches. Approach 1 works, approach 2 fails (I think I am
> missing somethig basic here).
>
> Approach 1: Everything in one WAR, share Registry via ServletContext:
>  - /myapp/web/
>  - /myapp/rest/
>  - Make Tapestry 5 application run in folder "web", by providing
> configuration SymbolConstants.APPLICATION_FOLDER in AppModule
>  - In web.xml: map the TapestryFilter to /web/*,
>  - In web.xml: add a Jersey Servlet and map it to /rest/*
>  - In Jersey resource: access the Registry instance stored in
> ServletContext
> and access my service like this:
>Registry registry =
> (Registry)context.getAttribute(TapestryFilter.REGISTRY_CONTEXT_NAME);
>EmployeeService service = registry.getService(EmployeeService.class);
>
> Approach 1 works, because TapestryFilter and JerseyServlet share the
> ServletContext (are part of same webapp). However, I would like to have
> separate WARs for the Jersey and for the T5 app. I may need this to
> configure different auth-method in  in web.xml for Jersey app
> than for T5 app.
>
> Approach 2: Separate WARs, share Registry via JNDI.
> - /myapp-web/
> - /myapp-rest/
> - In T5 app, after Registry startup, store the Registry instance in JNDI
> somehow
> InitialContext ic = new InitialContext();
> ic.rebind("java:registry", registry);
> - In Jersey app, access the Registry through JNDI and access my service:
>   InitialContext ic = new InitialContext();
> Object object = ic.lookup("java:registry");
> Registry registry = (Registry)object;
> EmployeeService service =
> registry.getService(EmployeeService.class);
>
> Approach 2 fails with ClassCastException in this line:
>  Registry registry = (Registry)object;
>  ClassCastException: org.apache.tapestry5.ioc.internal.RegistryWrapper
> cannot be cast to org.apache.tapestry5.ioc.Registry.
>
> I am using Jetty. I debuged it and found that object from lookup() has a
> class from a different classloader than class I cast it to, because they
> come from different contexts (each context has a separate classloader). I
> have little experience with storing objects in JNDI, I think I am missing
> something basic here, maybe JNDI is not even meant to be used like this
> Is it even feasible to share Registry through JNDI?
>
> Please share your thoughts, is there any other way to share my the Tapestry
> IOC Service from running T5 app to another web application, deployed in the
> same container? Is this even a good idea? Or should I keep all in 1 WAR?
>
> For the record, I also considered: business logic in a separate EJB layer,
> shared by both apps, both apps deployed to Glassfish. This environment is
> somewhat hard to configure for me, for example because tapestry-jpa
> conflicts with AS-managed persistence context. I would like to keep the dev
> environment simple and make use of live class reloading. I use Eclipse +
> maven + jetty.
> Thanks for any ideas.
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>