Stopping Component in a Virtual Host
Hi!
I'm doing a webservice that can be stop using a request, I had followed one
forum here. But I run in a trouble stopping the component in a virtual host set
up.
Here is the first testcase 1, I can stop the server using
http://localhost:8182/stop
///
// testcase 1//
///
public static void main(String[] args) throws Exception{
Component component=new Component();
component.getServers().add(Protocol.HTTP,8182); //Private Port
component.getServers().add(Protocol.HTTP,8183); //Public Port
MyApplication myApp=new MyApplication();
component.getDefaultHost().attach(myApp);
myApp.getContext().getAttributes().put(component, component);
component.start();
}
///
// MyApplication //
///
public class MyApplication extends Application {
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
router.attach(/stop, StopResource.class);
return router;
}
}
///
// StopResource //
///
public class StopResource extends ServerResource
{
@Get
public Representation requestGet() throws Exception{
((Component) getContext().getAttributes().get(component)).stop();
return null;
}
}
Here is a testcase 2 that is using a virtual host
///
// testcase 2//
///
public static void main(String[] args) throws Exception{
Component component=new Component();
component.getServers().add(Protocol.HTTP,8182); //Private Port
component.getServers().add(Protocol.HTTP,8183); //Public Port
InetAddress inet = InetAddress.getLocalHost();
String cannonicalHostName = inet.getCanonicalHostName();
component.getContext().getAttributes().put(component, component);
VirtualHost proxyHost = new VirtualHost(component.getContext());
proxyHost.setHostDomain(cannonicalHostName);
proxyHost.setHostPort(8182);
proxyHost.attach(/stop, StopResource.class);
VirtualHost loadBalance = new VirtualHost(component.getContext());
loadBalance.setHostDomain(cannonicalHostName);
loadBalance.setHostPort(8183);
loadBalance.setRoutingMode(Router.MODE_NEXT_MATCH);
component.getHosts().add(proxyHost);
component.getHosts().add(loadBalance);
component.start();
}
Here is the stacktrace for the testcase 2
Apr 20, 2010 10:01:27 AM org.restlet.resource.UniformResource doCatch
WARNING: Exception or error caught in resource
java.lang.NullPointerException
at
com.ti.itg.peit.peitcache.resource.StopResource.requestGet(StopResource.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.restlet.resource.ServerResource.doHandle(ServerResource.java:427)
at org.restlet.resource.ServerResource.get(ServerResource.java:592)
at org.restlet.resource.ServerResource.doHandle(ServerResource.java:474)
at
org.restlet.resource.ServerResource.doNegotiatedHandle(ServerResource.java:534)
at
org.restlet.resource.ServerResource.doConditionalHandle(ServerResource.java:270)
at org.restlet.resource.ServerResource.handle(ServerResource.java:764)
at org.restlet.resource.Finder.handle(Finder.java:515)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:495)
at org.restlet.routing.Router.handle(Router.java:735)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:495)
at org.restlet.routing.Router.handle(Router.java:735)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:152)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
at org.restlet.Component.handle(Component.java:385)
at org.restlet.Server.handle(Server.java:474)
at
org.restlet.engine.http.connector.BaseServerHelper.handle(BaseServerHelper.java:158)
at
org.restlet.engine.http.connector.BaseServerHelper.handleInbound(BaseServerHelper.java:167)
at
org.restlet.engine.http.connector.BaseHelper.handleNextInbound(BaseHelper.java:366)
at
org.restlet.engine.http.connector.Connection.readMessages(Connection.java:701)
at
RE: Stopping Component in a Virtual Host
Hi Thierry,
Thanks for the reply, i got it working on stopping without our
Application. But when I add the code for our Application, it seems it can't
fully exit the jvm. I tried it first without
loadBalance.attach(/webservice/PEITCache, new
MainPEITCacheApplication(c:\\webappsProperties\\cache.ccf)); it is working
find in shutting down the component, but once I add it it can't.
/
public static void main(String[] args) throws Exception{
final Component component=new Component();
component.getServers().add(Protocol.HTTP,8182); //Private Port
component.getServers().add(Protocol.HTTP,8183); //Public Port
InetAddress inet = InetAddress.getLocalHost();
String cannonicalHostName = inet.getCanonicalHostName();
VirtualHost proxyHost = new VirtualHost(component.getContext()) {
public Route attach(String pathTemplate, Restlet target, int matchingMode) {
target.getContext().getAttributes().put(component, component);
return super.attach(pathTemplate, target, matchingMode);
}
};
proxyHost.setHostDomain(cannonicalHostName);
proxyHost.setHostPort(8182);
proxyHost.attach(/stop, StopResource.class);
VirtualHost loadBalance = new VirtualHost(component.getContext());
loadBalance.setHostDomain(cannonicalHostName);
loadBalance.setHostPort(8183);
loadBalance.attach(/webservice/PEITCache, new
MainPEITCacheApplication(c:\\webappsProperties\\cache.ccf));
loadBalance.setRoutingMode(Router.MODE_NEXT_MATCH);
component.getHosts().add(proxyHost);
component.getHosts().add(loadBalance);
component.start();
}
MainPEITCacheApplication
///
public class MainPEITCacheApplication extends Application {
String cachePropLoc=null;
/**
* A method to instantiate MainPEITCacheApplication
* @param cachePropLoc String location of the cache property file
*/
public MainPEITCacheApplication(String cachePropLoc){
this.cachePropLoc=cachePropLoc;
}
/**
* Creates a root Restlet that will receive all incoming calls.
*/
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
/*
*
*/
//router.attach(/cache, CacheManagerResource.class);
router.attach(/, CacheManagerResource.class);
router.attach(/{region},CacheManagerResource.class);
TemplateRoute route= router.attach(/{region}/{dynamicurl},
CacheManagerResource.class);
Variable v=new Variable(Variable.TYPE_ALL);
route.getTemplate().getVariables().put(dynamicurl, v);
try {
CompositeCacheManager ccm =
CompositeCacheManager.getUnconfiguredInstance();
Properties props = new Properties();
props.load(new FileInputStream(this.cachePropLoc));
ccm.configure(props);
} catch (Exception ex) {
ex.printStackTrace();
}
return router;
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590305
RE: Stopping Component in a Virtual Host
Hello, it seems that non-daemon threads are still running. Could you check using the jstack utility (http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html)? You may have to shutdown the cache in your MainPEITCacheApplication#stop method (something like ccm.shutdown()). Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590351
RE: Stopping Component in a Virtual Host
Hi Thierry,
I had modify MainPEITCacheApplication to override the stop but
still not stopping
/
MainPEITCacheApplication
/
public class MainPEITCacheApplication extends Application {
CompositeCacheManager ccm=null;
String cachePropLoc=null;
/**
* A method to instantiate MainPEITCacheApplication
* @param cachePropLoc String location of the cache property file
*/
public MainPEITCacheApplication(String cachePropLoc){
this.cachePropLoc=cachePropLoc;
}
/**
* Creates a root Restlet that will receive all incoming calls.
*/
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
/*
*
*/
//router.attach(/cache, CacheManagerResource.class);
router.attach(/, CacheManagerResource.class);
router.attach(/{region},CacheManagerResource.class);
TemplateRoute route= router.attach(/{region}/{dynamicurl},
CacheManagerResource.class);
Variable v=new Variable(Variable.TYPE_ALL);
route.getTemplate().getVariables().put(dynamicurl, v);
try {
ccm = CompositeCacheManager.getUnconfiguredInstance();
Properties props = new Properties();
props.load(new FileInputStream(this.cachePropLoc));
ccm.configure(props);
} catch (Exception ex) {
ex.printStackTrace();
}
return router;
}
@Override
public synchronized void stop() throws Exception {
if(ccm!=null){
ccm.release();
ccm.shutDown();
ccm=null;
}
super.stop();
}
}
///
Jstack Output
///
C:\Program Files\Java\jdk1.6.0_03\binjps -l -m
5484 com.ti.itg.peit.peitcache.actions.TestApp c:\webappsproperties\slaveconfig.
xml
3828 sun.tools.jps.Jps -l -m
2056
3700
C:\Program Files\Java\jdk1.6.0_03\binjstack 5484
2010-04-20 20:11:19
Full thread dump Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing):
DestroyJavaVM prio=6 tid=0x003c7c00 nid=0x119c waiting on condition [0x000
0..0x00affd4c]
java.lang.Thread.State: RUNNABLE
RMI RenewClean-[10.10.132.184:50006] daemon prio=6 tid=0x03550800 nid=0x1610 i
n Object.wait() [0x03a1f000..0x03a1fa94]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x24606ab0 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked 0x24606ab0 (a java.lang.ref.ReferenceQueue$Lock)
at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(Unknow
n Source)
at java.lang.Thread.run(Unknown Source)
GC Daemon daemon prio=2 tid=0x0354ec00 nid=0x1278 in Object.wait() [0x039cf000
..0x039cfb14]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x245d7228 (a sun.misc.GC$LatencyLock)
at sun.misc.GC$Daemon.run(Unknown Source)
- locked 0x245d7228 (a sun.misc.GC$LatencyLock)
RMI Reaper prio=6 tid=0x0354c800 nid=0x1470 in Object.wait() [0x0397f000..0x03
97fb94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x245d6830 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked 0x245d6830 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at sun.rmi.transport.ObjectTable$Reaper.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
RMI TCP Accept-0 daemon prio=6 tid=0x0354b800 nid=0x1004 runnable [0x0392f000.
.0x0392fc14]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
- locked 0x245d6888 (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unkno
wn Source)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Thread-6 daemon prio=6 tid=0x0353c000 nid=0x570 waiting on condition [0x038df0
RE: Stopping Component in a Virtual Host
Hi Gerald, as you seem to use an auxiliary cache could you try something like RemoteCacheServerFactory.shutdownImpl( , Registry.REGISTRY_PORT ) before the shutdown of the cache manager? Or specify directly the host and port of the remote cache server. Bast regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590475
What to do about sessions?
Hi,
I'm using restlet with google app engine. I need to support session state. If a
user logs in, I want to remember that they're still logged in when they switch
between pages, so they don't have to keep re-authenticating.
I read through the posts here about sessions not being supported by restlet,
which I don't full comprehend (I am new to this).
I have a login servlet, and am doing something like this:
HttpSession session = request.getSession();
if(ProvidedUserParametersAreOK){
session.setAttribute(user, name);
then in my other servlets, I'd like to check if the user is still logged-in:
HttpSession session = request.getSession(false);
if (session.getAttribute(user) != null){
User user=(User)session.getAttribute(user);
//user logged in
but we don't have access to the session in our ServerResource derived servlets.
If a restful application is not supposed to support sessions, where would I
keep this session state information then? Just wondering how to implement this
really,
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590519
Re: What to do about sessions?
Hi dj, session are strictly forbidden in REST, because the scalability advantage of restful applications will get lost, because caches wont work. For details see the dissertation of Roy Fielding, the founder of the REST architecture style, espacially chapter 5 (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). Because restful application is not supposed to support sessions (as you wrote), they are not uspported in Restlet. The restful way is to use HTTP autentication. You just need to use a Guard in your Restlet server deployment, e.g. with HTTP-Basic as authentication scheme. The other things do Restlet and the browser for you, but I can't say if the Google App support it. With a browser (e.g. Firefox or IE) it works. best regards Stephan ___ NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit! http://produkte.web.de/go/02/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590531
RE: Stopping Component in a Virtual Host
Hi Thierry,
Got it working now, it with the CompositeCacheManager, I just need to
clean up everything.
Thanks
public class MainPEITCacheApplication extends Application {
String cachePropLoc=null;
/**
* A method to instantiate MainPEITCacheApplication
* @param cachePropLoc String location of the cache property file
*/
public MainPEITCacheApplication(String cachePropLoc){
this.cachePropLoc=cachePropLoc;
}
/**
* Creates a root Restlet that will receive all incoming calls.
*/
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
/**
*
*/
router.attach(/, CacheManagerResource.class);
router.attach(/{region},CacheManagerResource.class);
TemplateRoute route= router.attach(/{region}/{dynamicurl},
CacheManagerResource.class);
Variable v=new Variable(Variable.TYPE_ALL);
route.getTemplate().getVariables().put(dynamicurl, v);
try {
CompositeCacheManager ccm=null;
ccm = CompositeCacheManager.getUnconfiguredInstance();
Properties props = new Properties();
props.load(new FileInputStream(this.cachePropLoc));
ccm.configure(props);
} catch (Exception ex) {
ex.printStackTrace();
}
return router;
}
@Override
public synchronized void stop() throws Exception {
/**
* Close any open processes
*/
String[]
cacheNames=CompositeCacheManager.getInstance().getCacheNames();
int len=cacheNames.length;
for(int i=0;ilen;i++){
CompositeCacheManager.getInstance().freeCache(cacheNames[i]);
}
CompositeCacheManager.getInstance().release();
CompositeCacheManager.getInstance().shutDown();
super.stop();
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590534
RE: What to do about sessions?
Hello, as said Stephan, servlets sessions are not supported. If a user logs in, I want to remember that they're still logged in when they switch between pages, so they don't have to keep re-authenticating. There is no magic. If you have a look at each request issued from the browser, you will see that there is one piece of information that contains the session id (either the cookies header or the url) = each request is somewhat authenticated. When your browser allows cookies, the browser is in charge to generate correct request. In the case your browser does not allow cookies, the servlet container is in charge to generate right urls. Web browsers are also able to authenticate each request using real authentication based on HTTP_BASIC (coupled with https, that's better) or HTTP_DIGEST. The browser is able to ask your credentials, negotiate with the server and authenticate each requests. So, based on this browser feature (generation of requests with correct cookies values or correct basic or digest values), you can set up authentication on server side using subclasses of the Authenticator class. the aim of an authenticator is to parse the request and check that the request is sent by a known and verified user. The Restlet framework provides a ChallengeAuthenticator class that handles HTTP_BASIC and HTTP_DIGEST challenge schemes. There is no Authenticator based on cookies, but it should not be difficult to cope with it. Please note that Authorization is a second phase where the question to answer is : Is this user able to send this request to this resource? The Restlet provides another feature for that : the Authorizer class. Have a look at this page, especially at the sample code at the bottom. It should help you (http://wiki.restlet.org/docs_2.0/13-restlet/46-restlet.html) Feel free to ask for more details. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590610
RE: Re: What to do about sessions?
Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591
Re: What to do about sessions?
Dj, I'm glad you asked this. I've really lucked out so far and have always worked in an environment that uses client certificates for authentication. The identity of the user is established on every single connection, and I never have to worry about it. But in the near future, I'm going to have to solve the same problem that you're looking at now. You make some astute observations, HTTP_BASIC is only safe over HTTPS, which is very limiting, especially when deploying to GAE. HTTP_DIGEST has some poorly understood compatibility problems with different HTTP clients, furthermore, it isn't what GAE uses natively. It seems that for the GAE edition in particular it would be nice to have an Authenticator that could integrate with the GAE APIs. I'm sure if it isn't done by the time I have to tackle that project that I'll wind up writing one. Does the restlet team have any specific advice for creating a subclass of Authenticator that can get the Google account identity? Specifically a way to use a restlet to write the login example given on this link: http://code.google.com/appengine/docs/java/users/overview.html -Matt On Apr 20, 2010, at 11:37 AM, dj wrote: Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590628
Re: Restlet OAuth extension
I have been away from Restlets for a long time... far too long. I was just looking at the API for the Restlet extensions - I can't find OAuth library (org.restlet.ext.oauth) there. Is that what the bug below is talking about (documentation missing beside the JavaDocs)? Thanks for clearing this up :) -T On Wed, Oct 28, 2009 at 7:15 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi there, We are definitely planning to upgrade this extension for 2.0 as indicated by this issue: Improve OAuth extension http://restlet.tigris.org/issues/show_bug.cgi?id=606 We are welcoming contributions to help us with this extension, for migration to ServerResource, update to the latest OAuth library and documentation in the wiki. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : smarter [mailto:suneel.mar...@gmail.com] Envoyé : vendredi 16 octobre 2009 02:15 À : discuss@restlet.tigris.org Objet : Re: Restlet OAuth extension smarter wrote: The current Restlet OAuth extension is based on the previous 1.1 restlet api. It still uses the now deprecated 'Resource' class. Will this be upgraded to current 2.0 version of Restlet api? Also its still using the OAuth 1.0 core package and not the recent 1.0A specification which fixes a security issue in the older version. -- View this message in context: http://n2.nabble.com/Restlet-OAuth-extension-tp3817152p3832815.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24080 67 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412071 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590994
