Re: [Resin-interest] Eclipse Plugin
Hi Emil,
Emil Ong schrieb:
On Wed, May 13, 2009 at 08:22:19PM +0200, Michael Ludwig wrote:
I added -consoleLog to my eclipse.ini, but I have no idea where the
log is going. If it is just the console window in the IDE, there is
nothing special to see, just the usual Resin startup messages plus
additional debug info my application generates.
Can you try running eclipse from the command line and adding the
-consoleLog? On Windows it's supposed to pop up a Java console
window, but it might not work in eclipse.ini.
No output is shown on STDERR when starting eclipse.exe -consoleLog.
Does anyone here know how this is supposed to work?
But with this in place configuration, all I get is 404. I tried all
kinds of possible context paths, but none seems to work. Which is sort
of logical, as I don't see my application's startup blurb in the console
log. On the other hand, Resin mentions it (DbXml01):
[20:13:46.593] {main} WebApp[http://default/DbXml01] active
As per your instructions, I configured finest level logging in
plugins/com.caucho.resin.eclipse_4.0.0/conf/resin40/in-place.xml,
and that revealed the problem. The context path /DbXml01 is accepted,
but somewhere along the way, there is a manifestation of the typical
pathname-with-spaces issue.
My %UserProfile% is in:
C:\Dokumente und Einstellungen\MiLu - which is like:
C:\Documents and Settings\MiLu
And this gets split on spaces, so the resulting path is completely
wrong:
{http--8099-3} real-path /gurke - C:\Dokumente\gurke
{http--8099-3} real-path /gurke/index.jsp - C:\Dokumente\gurke\index.jsp
{http--8099-3} real-path /gurke/index.php - C:\Dokumente\gurke\index.php
{http--8099-3} real-path /gurke/index.html - C:\Dokumente\gurke\index.html
So I guess you just need to quote the path at the appropriate places.
20:14:59,20 C:\MILU\dev\ds
# netstat -p tcp -na | findstr 8099
TCP0.0.0.0:8099 0.0.0.0:0 ABHÖREN
TCP127.0.0.1:4394 127.0.0.1:8099 SCHLIESSEN_WARTEN
TCP127.0.0.1:8099 127.0.0.1:4394 FIN_WARTEN_2
The port I specified is taken into account, the address isn't.
It's trying to open http://localhost:8099/DbXml01 and not getting
anything? It looks like Resin's finding the webapp, so something else
must be the issue.
In any case it didn't find the webapp because I didn't see the webapp
startup blurb in the server log, and given the pathname issue, this is
understandable.
Michael Ludwig
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] CipherSuites for Jsse in resin 3.1.6
Thanks for adding the notes to issue 3431. I was hoping that Scott and Emil could chime in where I think the changes need to happen. We're wanting to implement 3.1.6 (up to 3.1.9) in our production environments, and this change is key to that development. If this is a logical place to start, we may implement 3.1.6x until 3.1.10 is available. ;) Have you guys had a chance to take a quick look, yet? + jay Scott Ferguson wrote: On May 1, 2009, at 4:33 PM, Jay Ballinger wrote: Howdy, Please refer to: http://bugs.caucho.com/view.php?id=3431 (which is a reopen of) http://bugs.caucho.com/view.php?id=2360 I've added this information as a note to 3431. Now that we've released 4.0.0, we can start clearing out the old, stalled bug reports. -- Scott We're using Resin Pro 3.1.6 and trying to limit the cipher suites for JSSE. I couldn't find the documentation, but through trial and error was able to discover that http stanza allows this syntax for setting ciphers... host port=443 host=some.host jsse-ssl cipher-suitesSSL_RSA_WITH_RC4_128_MD5,[more]/cipher-suites key-store-type... key-store-file... password... /jsse-ssl /host But running THCSSLCheck didn't show any change to the ciphers. I dove down in to com.caucho.vfs.JsseSSLFactory and had to make the following changes... 1) in the public QServerSocket create(InetAddress host, int port) method, there is a check for _cipherSuites != null. That if stmt includes the following line: sslContext.createSSLEngine().setEnabledCipherSuites(_cipherSuites); While this appears to do what I need, it doesn't appear to really affect anything. I'm not sure where the new SSLEngine is used. The SSLServerSocketFactory is established in the same if block, but nothing new is set there. 2) there is some commented code below that method that looks like it was setting protocols - pretty close to ciphers. I added the following just before the return stmt: sslServerSocket.setEnabledCipherSuites( _cipherSuites ); And now I see a difference with THCSSLCheck. Scott, I haven't looked any further than JsseSSLFactory and Port, so I don't know if this was supposed to be handled somewhere else. And I'm not sure if this is still an issue with 3.1.9, or the 3.2/4 code. I think we're in the minority running JSSE, but it works well enough for us. We upgraded to 3.1.6 because this was reported as fixed on this version, but obviously this isn't. Maybe there might be confusion with the https.cipherSuites system property/java-args usage versus the socket cipher suites - which would be my bad for not asking for the right thing. If I understand the https.cipherSuites properly (now), that is when you run as a client versus the server. To set server ciphers you need to interact with the API directly - like the SSLServerSocketFactory does. This may be why 3431 was opened. Is this a reasonable fix if we were to run 3.1.6mine? Has this been fixed in newer revisions? Are there others running JSSE with an interest in limiting the cipher suites and possibly the protocols? + jay ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Automating virtual hosting....
On May 18, 2009, at 10:09 AM, Peter Amiri wrote: Thank you everyone for your assistance on getting this setup. I now have a directory where I can drop individual config files for each domain and get them integrated into the resin.conf file using resin:import. The one issue I have with this is that it requires a restart of Resin to discover the newly added file which will kill everyones sessions and forces a reload of all the web apps. Not a very appealing feature from the customer perspective ;-) Hmm. That's an interesting point. Even if the directory change was detected, Resin would force a restart because the config file affects the cluster, even though you might just be adding a new host. In other words, it wouldn't be sophisticated enough to know that adding a host is isolated. Someone told me I could setup a cluster with two Resin instances running on the same server so if the instances had to be restarted the sessions would be preserved. Does anyone know how to do this? It would be a little more complicated because you'd also need a load balancer. You can use a single resin.xml file. Each Resin server/virtual-host would have its own cluster. (A cluster for Resin is a collection of identically-configured virtual hosts. You can have one server in a cluster.) Assuming you have a single HTTP port, you'd need a load- balance instance of Resin to forward the requests to the proper backend Resin instance. -- Scott -Peter On May 12, 2009, at 4:33 PM, Peter Amiri wrote: Thanks Scott for all the help. This is how far I've gotten. I have added the import block to Resin conf file as follows: resin:import fileset dir=/var/www/vhosts/resinconf include*.xml/include /fileset /resin:import I have also created a directory at : /var/www/vhosts/resinconf and placed the following file in it: showmyip.xml and the file contains the following: cluster xmlns=http://caucho.com/ns/resin; host host-name=www.viditag.com host-aliasviditag.com/host-alias root-directory/var/www/vhosts/viditag.com/httpdocs/root- directory web-app id=/ root-directory=. / /host /cluster When I restart Railo it starts up and doesn't give any errors. But when I try to hit the virtual host I get an error that is indicative that the host block was not loaded. So it seems that the resin:import command doesn't through any errors but cannot find or access the showmyip.xml file. Any ideas what could be causing this? I've alrady chmod the resinconf dir and the showmyip.xml file to 777 to make sure it is not a permission issue but that didn't help matters either. -Peter On May 12, 2009, at 12:19 PM, Scott Ferguson wrote: On May 12, 2009, at 11:33 AM, Peter Amiri wrote: Scott, Do you know what the syntax of the actual xml files should be? Is there a container that should hold the host block in the individual xml files? resin:import always uses the containing context for the top-level xml, because it's like an extension of the current context. Since your host import is inside the cluster, the syntax of your *.xml would be cluster xmlns=http://caucho.com/ns/resin; host ... ... /host /cluster -- Scott -Peter On May 12, 2009, at 11:07 AM, Scott Ferguson wrote: On May 12, 2009, at 10:49 AM, Peter Amiri wrote: I am trying to automate the process of integrating Resin with a cPanel hosting environment. For each customer that signs up for a cPanel account I need to add the virtual hosting tags to the Resin conf file manually. Currently the code block that is added is similar to this: host host-name=www.domainname.com host-aliasdomainname.com/host-alias root-directory/home/path_to_domain/public_html/root- directory web-app id=/ root-directory=. / /host These blocks are added to the cluster.../cluster block within the resin conf file. Unfortunately the path to the domain is not based on the domain name so I cannot setup dynamic virtual hosting based on a path. But I wanted to know if there was a way to write these individual blocks into separate files that got included or imported by the Resin conf file. You can try the resin:import with the fileset syntax: cluster id= ... resin:import fileset dir=hosts include*.xml/include /fileset /resin:import That sounds like it's what you're looking for. -- Scott In other words I can take into a hook for cPanel and create a text file with the contents of the block above (or some new lines if needed) and save it as something like domain.conf. Then I would like to have the resin conf file automatically read in all these domain based conf files based on the path to the file locations and the extension so any new domain conf file that is dropped into the directory would automatically be included or become part of the Resin conf file. Is this doable with Resin 3.1? -Peter
Re: [Resin-interest] Automating virtual hosting....
Scott, Thanks for the input. May be I'm going about this the wrong way. What is the best practices for setting up shared virtual hosting of Resin. I basically want to provide Railo (http://www.getrailo.org) hosting. Railo is a CFML engine that can run on top of any J2EE container. Right now I am using the cPanel control panel and have hooks programmed in to create the necessary domain.xml files which are tapped into a single install of Resin. The current architecture works ]like this, when a user signs up, a new domain.xml file is created and stored in a config directory. Then the script does a touch on the resin.conf file to force a restart. The resin.conf includes the newly created domain.xml using the resin:import tag that reads all the xml files in the config directory. So everything is working and automated, I just wanted to know if there was a way to make it so the applications didn't see the service go up and down. Any advice you could provide on this would be appreciated. -Peter On May 19, 2009, at 9:25 AM, Scott Ferguson wrote: On May 18, 2009, at 10:09 AM, Peter Amiri wrote: Thank you everyone for your assistance on getting this setup. I now have a directory where I can drop individual config files for each domain and get them integrated into the resin.conf file using resin:import. The one issue I have with this is that it requires a restart of Resin to discover the newly added file which will kill everyones sessions and forces a reload of all the web apps. Not a very appealing feature from the customer perspective ;-) Hmm. That's an interesting point. Even if the directory change was detected, Resin would force a restart because the config file affects the cluster, even though you might just be adding a new host. In other words, it wouldn't be sophisticated enough to know that adding a host is isolated. Someone told me I could setup a cluster with two Resin instances running on the same server so if the instances had to be restarted the sessions would be preserved. Does anyone know how to do this? It would be a little more complicated because you'd also need a load balancer. You can use a single resin.xml file. Each Resin server/virtual-host would have its own cluster. (A cluster for Resin is a collection of identically-configured virtual hosts. You can have one server in a cluster.) Assuming you have a single HTTP port, you'd need a load- balance instance of Resin to forward the requests to the proper backend Resin instance. -- Scott -Peter ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] MDB Config Using CanDI
Right, and maybe then we will have support for @Current @MyQueue
BlockingQueueMyQueueItem also.
Yeah, the (remote) service/servlet stuff will be cleaner with that syntax.
On Tue, May 19, 2009 at 9:13 AM, Scott Ferguson f...@caucho.com wrote:
On May 18, 2009, at 10:51 PM, Scott Hernandez wrote:
I was going to start converting a bit of the config from the xml
mapped names to the actual class names in our resin-web.xml . However
the names have changed; Is there an example of how this works?
!-- Doesn't work because the destination cannot be found --
ejb:MessageBeanConfig destinationName=delivery
class=org.subethamail.core.queue.DeliveryListener/
ejb-message-bean is a complicated case because the real bean is your
DeliveryListener. A similar kind of issue applies to remote service
configuration, and bam-service and even Servlets.
I think the right solution is to configure the DeliveryListener with
annotations:
subethamail:DeliveryListener
MessageBean destinationName=delivery/
/subethamail:DeliveryListener
Or for servlets:
mypkg:MyServlet
WebServlet url-pattern=/foo/
/mypkg:MyServlet
Where @MessageBean and @WebServlet are known annotations. The CanDI
spec's SPI has just changed radically in the last 3 weeks, making that
kind of configuration possible (it's still a few weeks before Resin
supports it, though.)
So, until that's supported, you'll want to stick with ejb-message-
bean.
-- Scott
!-- works --
ejb-message-bean
class
=
org
.subethamail.core.queue.DeliveryListenerdestination#{delivery}/
destination/ejb-message-bean
Thanks in advance,
Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Watchdog Chroot
Hi, I am using the following watchdog.conf to CHROOT jail resin. resin xmlns=http://caucho.com/ns/resin; management user name=harry password=MD5HASH==/ /management watchdog-manager watchdog-port6617/watchdog-port watchdog id=www.domain.com resin-conf/resin/conf/hosts/www.domain.com.conf/resin-conf resin-root/resin//resin-root chroot/resin/thehost/www.domain.com//chroot /watchdog /watchdog-manager /resin After running the watchdog and starting the domain, I am able to use file.io to read any file on the server. I want to prevent virtual hosts from reading files that they shouldn't have access to. I think that I must be missing something somewhere, but I'm not sure what? I know that CHROOT/JAIL typically has many steps involved with Tomcat, is that the same with Resin? Last twistIf I am running Resin in conjunction with Apache does that cause additional CHROOT issues? Can resin handle multiple certs for virtual hosts using a watchdog.conf setup? I primarily use apache for mod_rewrite ssl certificates. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
