Re: [Resin-interest] Resin 4.0.0 embedded
Hi Scott, S'està citant Scott Ferguson f...@caucho.com: I've added a bug report for this. It's been something that's been bugging me a bit. For normal Resin, we take control of the logging as soon as it's launched (so you could duplicate that -D... header), but we don't have a clean way of managing the logging if we're not in control at the start. I understand. The options that I've seen in other embedded containers are: .- Allow seetings to be configured through the API. .- Allow a partial configuration file where some settings can be specified. Both options have pros and cons, depending on whether you want to control everything programatically or just start it from your Java class and be able to configure it externally. In my case, I'd probably go for the second option, but that's just because it is the option that better suits my particular needs :D. .- The embedded engine requires a JDK for compiling as it needs a Java compiler, but... is it possible to configure it to use an embedded compiler like Apache Jasper or similar so it can be packed with the engine? I'm not sure I understand. Jasper is the JSP implementation. It isn't a compiler. Well, I might be wrong as I did not get into details, but with Tomcat a library is included that reads jasper-compiler.jar and that is in charge, if I'm not mistaken, of compiling the JSPs. And I can run that version using a JRE, so I asumed it included everything that was needed, JSP compiling included. You can bundle Resin with the eclipse compiler. We already have a compiler=eclipse option. I know that and I know how to configure it in the resin.conf file, but how does one configure the embedded version to use it? Is is detected automatically if is is found in the classpath? Otherwise, it might be another candidate to be included in the API/partial config file. That sounds fine. Great. I'll provide a separate package licensed under the GPL and let you revise it in case you want to add something for the Resin part. On a related note, I cannot get the embedded container to run a .war file and I came across a quite weird thing. I'm setting it like that: --- WebAppEmbed theApp = new WebAppEmbed(/); theApp.setRootDirectory(C:/tmp); theApp.setArchivePath(D:/Apps/deploy/Wembed/demo.war); --- After starting the server, I see that a WEB-INF directory is created in c:/tmp and a single empty directory classes inside it. Nothing else is there, so all I get are 404s. And then the weird thing. I wanted to test if using it with my full Resin 3.1.5 installation, so I changed the host configuration to be like this: ... web-app id=/ archive-path=D:/Apps/deploy/Wembed/demo.war/ ... The result was that it tried to deploy the application in the Resin directory, removing all the files... So Resin ended up removing itself! I'll have to try with the latest versions, but it looks like a problem :). S! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory leak - in Resin?
Hi, Using that .war as a sample application, I did some more tests and found some things that might be interesting: I added groovy-1.5.7.jar, hibernate-3.2.6.ga.jar and scala-compiler-2.7.2.jar to WEB-INF/lib. Nothing is done with them, they simply live there. Important data: total size for WEB-INF/lib: 10.3 MB. I then deployed the application, start it and here's some data I gathered after accessing the application a couple of times and hitting Force Garbage Collector until the memory is stable: Heap Memory used: 31MB Instances of com.caucho.loader.EnvironmentClassLoader: 1 I then re-save web.xml so the context is reloaded, access and force GC until memory is stable again: Heap Memory used: 41MB Instances of com.caucho.loader.EnvironmentClassLoader: 2 Once again: Heap Memory used: 51MB Instances of com.caucho.loader.EnvironmentClassLoader: 3 Focusing on the last memory snapshot the 3 EnvironmentClassLoader come from (shortest GC roots): 1.- contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] 2.- _classLoader of com.caucho.server.dispatch.Invocation - _invocation of com.caucho.server.http.HttpRequest [Stack Local] - 3.- loader of org.codehaus.groovy.tools.shell.util.Preferences$1 - class of org.codehaus.groovy.tools.shell.util.Preferences$1 - [1] of java.util.prefs.PreferenceChangeListener[3] - prefListeners of java.util.prefs.WindowsPreferences - STORE of org.codehaus.groovy.tools.shell.util.Preferences - [771] of java.lang.Object[2560] - elementData of java.util.Vector - classes of com.caucho.loader.EnvironmentClassLoader - contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] They are ordered using order of appearance (in the first memory SS, one like 1 is present, after the first restart one like the 2 is present). And looking at one of the suspected classes to be replicated, org.codehaus.groovy.tools.shell.util.Preferences, you can see that indeed there are 3 instances of that class, each one loaded by a different EnvironmentClassLoader. So, I would say there is indeed a leak and the jackpot would be to find out why the EnvironmentClassLoader instances are not being cleaned. Without knowing how Resin is internally supposed to work and which loaders are supposed not to be there, it's difficult to know. As the classes inside the lib directory are not even used at all, one would suspect is a Resin internal issue, but seeing Preferences classes and ThreadLocal in the mix makes the whole thing quite suspicious :). Any idea or test to find out more? D. Seems to me nothing has changed in this regard in the 4.0 snapshot. I did my leak test as previously described, see below, and no classes were unloaded. - Dowload http://jiderhamn.se/leak.war - Add some JARs to the WEB-INF/lib directory; preferrably a couple of large ones like spring.jar and hibernate.jar (don't use Resin JARs though). - Drop the WAR in a clean installation of Resin - Hit http://...:nn/leak (once is enough) - Force a redeploy by either deleting the webapps/leak dir or touch:ing leak.war - Hit http://...:nn/leak again - Repeat the last two steps for as long as you'd like /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote programmatic authentication
While on that topic... I have been fighting through the years, since version 3.2, to get the servlet spec. to improve the security part but well, not very successfully one could say. I guess not being famous or working for a mega-vendor does not help :). Bitching at forums and blogs (sending feedback to the servlet spec feedback email was like throwing it to the trash can) I've managed to get some attention lately, http://weblogs.java.net/blog/sekhar/archive/2009/03/weblogic_to_gla.html http://forums.java.net/jive/message.jspa?messageID=337626#337626 so if some of you that think along the same lines would also to say something, we might get the small voices to the be heard if we push together. So feel free to add your feedback, please, so at least they cannot say any longer that users do not complain so it must be nothing needs to change. On a side node, what we did long ago was to separate the security settings from the business logic and also divide it in two parts: .- The security model specifies the relationship between roles and users and if a user is authenticated or not. .- The security policy specifies which roles are required to perform a request, this can be done per-request-on-the-fly so the same URL can have different requirements depending on the parameters, something on the session, the context, the date... the weather ;)... whatever. The security engine asks both entities and decides (it can decide first if a user is logged in or not, and knowing which roles are required for that specific request, deny or accept the request, redirect to the login page...). Some information is passed to the business logic in case it is required for something (usually the username) and some more complex checkings can be done, but in many applications that is more than enough. That also allows us to re-use the security model between applications, sharing the security policy is not that common as it tends to be app-specific, and be able to deploy the applications on any container. In any case, I wish it was part of the spec. so I did not have to maintain the code myself, and we cannot make use of isUserInRole() etc., but in any case it's worked for us since 1998, so I think we already made the ROI positive :). S! D. S'està citant Scott Ferguson f...@caucho.com: On Mar 19, 2009, at 8:30 PM, Jeff Schnitzer wrote: The problem is, j2ee automatic authentication is nearly useless. Correct. It doesn't allow for autologin cookies nor does it allow me to sign up new users - they would have to then log in again. It blows my mind that a decade later the servlet spec hasn't addressed these simple needs. Yep. Almost as bizarre as not having multipart/mime (upload) support. Resin 4.0 has refactored Resin's login/authentication (because our old model really didn't make much sense.) The new Login handles servlet/http interaction and the Authenticator handles pure user/credentials (the old model mixed the two concepts into the old ServletAuthenticator.) So, the capabilities you're looking for would be added to a Login class. I don't know if you're looking for customizing the Login, or if you want a more general capability in our AbstractLogin. Since the new configuration uses Java DI, your application can grab the login. The configuration looks like: sec:BasicLogin/ And then you could use @Current AbstractLogin _login; Or @Current BasicLogin _login; (At present, the Login interface itself wouldn't be useful from a programmatic standpoint, while we could add methods to AbstractLogin.) -- Scott I need a way, in my web app, to programmatically say to the container authenticate as this user/pass. Then these credentials will be used for further calls into the EJB tier or for responding to HttpServletRequest.isUserInRole() calls. Of course at the SPI level these will end up calling into my Resin Authenticator. This is a pretty common problem, there must be a Resin way to do it. In JBoss5, it looks like this: SecurityClient securityClient = SecurityClientFactory.getSecurityClient(); securityClient.setSimple(user, password); securityClient.login(); Thanks, Jeff On Thu, Mar 19, 2009 at 7:38 PM, Aaron Freeman aaron.free...@layerz.com wrote: #2 is still a mystery to me. I'm in a servlet, how do I programmatically tell the container to log me in with a username and password? This page has a good overview of how to do it: http://www.informit.com/articles/article.aspx?p=24253seqNum=7 So you set up your security constraints in your resin.xml and reference a custom authenticator inside the login-config. The create your custom authenticator by AbstractAuthenticator. Note the code in the example is referencing: com.caucho.server.http.AbstractAuthenticator but I think you want to extend com.caucho.server.AbstractAuthenticator instead, as I think the .http. version is deprecated. - Aaron
Re: [Resin-interest] Perf Issues
From our years using Resin and other containers, even though basically Resin, we have found basically 2 things that containers do not like: .- Swap memory. I know it's stating the obvious, but when your app is running out of memory and the GC starts working like frenzy, the worst it can happen is that the memory it is working with is on disk. That's where the CPU usage starts going up the roof and there's no way to stop the JVM but with a hard kill. .- Restarting the context. Yeah, contexts should not be restarted in production, but sometimes it happens. No matter how good a container is or how careful you are with your application, there are many third-party libraries that were not really well thought-out for a multi-classloader environment and they leave dangling references, which in many cases means the old classloader is not properly cleaned and retains, sort of, a copy of all your WEB-INF/lib/.jar's in memory. Unless you do all on your own, we consider this one a lost battle, because there are so many popular libraries that cause such problems... We don't use mod_caucho, so we don't usually have problems with Apache, so in our case we simply make sure to stay in the safe RAM memory zone and restart the servers once a day just to stay on the safe side as well. There are some nodes we don't restart and can stay up for months, but our environment is many small applications and they don't need to be 24/7, so that works better for us. From your description it looks more probable to be a problem of your application, but even if it is not, as the other people recommended, a memory profiler should do wonders to find out what's going on. Take a memory snapshot when the application is in regular usage and then another when the memory starts growing too much and compare them. I've used YourKit Java Profiler in those situation with the compare-snapshots option and worked quite well. Many other profilers also have that capability. S! D. S'està citant Jeff Schnitzer j...@infohazard.org: It's also worth mentioning that for serious application tuning, there is no substitute for a good profiling tool. In the past I have had great results with JProfiler: http://www.ej-technologies.com/products/jprofiler/overview.html I've even gone so far as to take one node in a production cluster, give it a reduced load profile at the balancer (because profiling slows things down considerably), and run the profiler against it live. You'll be amazed what you discover. Jeff On Sat, Mar 21, 2009 at 7:39 AM, Adam Allgaier allgai...@yahoo.com wrote: I would plug jconsole into your resin instance and watch what's happening to the JVM memory. Could be loose open threads (and large thread size) that grows over time and eats up free memory. Restarting would kill all the threads and free the memory. http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html Adam - Original Message From: Stargazer starga...@blueyonder.co.uk To: General Discussion for the Resin application server resin-interest@caucho.com Sent: Saturday, March 21, 2009 4:39:56 AM Subject: Re: [Resin-interest] Perf Issues Ronan Lucio wrote: Hi, We have had a perf issue. Our servers have 4Gb RAM. It has just Resin and Apache installed. The problem is, when I start Resin, the whole server uses about 2.5 Gb RAM After that memory usage keep growing til it reachs the 4Gb RAM, use swap and so on. After few hours the application start getting slow. Analyzing the server sources, it's using so low CPU, load about 1... I see none overload evidence, except for RAM memory. So I just restart Resin and/or Apache and application gets fast again, but few ours later it will raise the same issue. I have been suffering from exactly those symptoms for years. Do your httpd processes consume all the swap, with top showing some at 450Mb? (default httpd.conf values) I.e does restarting apache alone, and not resin, cause the swap to drop back down to normal until the next slow growth starts it all again? That is my pattern. So when I profile resin theres no unusual growth even through the whole server is effectiviley dead until restart. Given that, whos to blame? Could mod_caucho somehow be at fault even though resin itself is ok? I have another identical server running a couple of PHP CMS apps, no resin or java in sight - because of this problem actually. The plan is to move everything over when stable but these have become too critical to play with. Their typical httpd swap use is 25Mb, and its the default httpd.conf. I would dearly love to know what the httpd on the failing server thinks it needs to hold onto 450Mb for, without tweaking there could be 20 of these. There are other non-quercus PHP apps running on that server btw. My solution is to kill child httpd processes at a far quicker rate than you'd normally want, and it works of
Re: [Resin-interest] reverse proxy support like ProxyPass in apache?
Hi, In our case, it is usually enough to use mod_proxy with simply a ProxxPass and ProxyPassReverse directive, forwarding complete directories to the back end. That means we forward all requests to the applications, which reside in another machine in the backend, as they also include styles, images... One could configure some requests to be served directly by Apache, but that would mean we would have to split the applications in two pieces, one to reside in the Apache host, the dynamic one to reside in the application server... and that is something we don't want, due to the number of applications we have to mantain. In any case, in those specific cases where we needed to proxy specific types of requests, we would then use mod_rewrite and then mod_proxy, as the version of Apache we use, for other unrelated reasons, still does not have ProxyPassMatch. So, even if ProxyPassMatch is broken, you could still go back to the good ol' mod_rewrite/mod_proxy combo for those specific needs. S! D. S'està citant david day yaya...@gmail.com: This is a smashing idea, and I feel like an idiot for not seeing it. Unfortunately, ProxyPassMatch is broken in the RPM based RedHat Apache. This is at the same time mod_caucho will not build on any new CentOS or RedHat servers. Is your use of mod_proxy fairly basic, or have you been required to do some imaginative directives with regex? At least with mod_proxy, I can upgrade Apache and utilize ProxyPassMatch where mod_caucho fails under any configuration. I'm not excited about this prospect either, but there is nothing we can do about mod_caucho. You have given me another option out of this problem. David ___ 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] Profiling...
Hi,
On Windows, the DLLs have to be somewhere in the PATH, not
LD_LIBRARY_PATH which is a *nix thing. Moving them to Windows\System32
works as that's part of the standard PATH, but you can also do it just
starting Resin with a .bat file with something like...
***
set PATH=C:\Wherever\Your\DLLs\are;%PATH%
set JAVA_TOOL_OPTIONS=your-profiler-extra-options %JAVA_TOOL_OPTIONS%
httpd.exe
***
I use something like that successfully with YourKit Java Profiler and
Resin 3.1.X, 3.2.X (in this latter case it is resin.exe instead of
httpd.exe) and I didn't have to move any DLLs around, which really
helps when you have to upgrade your profiler.
I hope it helps,
D.
PS: I have not used the -Xdebug, so I'm not sure if that affects or not.
S'està citant Jan Simacek pnept...@yahoo.com:
On Windows (tested on vista but should work elsewhere) for me worked copying
all the dlls from jprofiler6\bin\windows to Windows\System32 cause that's
one of the default locations where windows look for dll's
Andrew Fritz-2 wrote:
Hmm... Ok, I think you may have it. I copied the jprofiler tree instead
of installing it. I bet it adds itself to my LD_LIBRARY_PATH.
I tried removing the debug options already with no luck.
In any case, I'll try looking for a .so file tomorrow and if that
doesn't fix it, I'll try the verbose option.
Thanks!
Andrew
Knut Forkalsrud wrote:
Andrew Fritz wrote:
Regardless, I still get a Could not find agent library on the library
path or in the local directory: jprofilerti.
The profiler likely comes with a binary, a file whose name end in .so,
at least for Linux. For jprofilerti the file name would be
libjprofilerti.so I think. Make sure that file is available to the
dynamic loader by for example setting the environment variable
LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac if I remember
correctly) or just copy it to ${resin.home}/libexec/ if you have such a
directory.
-Knut
PS: I still think removing -Xdebug is worth an attempt. I had very
similar symptoms and that change did the trick.
___
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
--
View this message in context:
http://www.nabble.com/Profiling...-tp16572976p22164339.html
Sent from the Resin mailing list archive at Nabble.com.
___
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] Quercus + Web Services / Zend
Hi again,
I think I found something related to the issue, as Quercus seems to
have some problems with PHP static members.
I created the following test:
***
?
class Test
{
protected static $_instance = null;
protected $_variable = null;
/**
* Singleton instance
*/
public static function getInstance()
{
$reflection = new ReflectionClass('Test');
foreach ($reflection-getProperties() as $property) {
$name = $property-getName();
echo Member: .$name.BR /
}
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
$testInstance = Test::getInstance();
?
***
If I execute the test under regular PHP, the result is:
---
Member: _instance
Member: _variable
---
If I execute it under Quercus, I just get
---
Member: _variable
---
The strange thing is that accessing the $_instance static memeber in
this little test works, but a very similar code is inside
Zend_Controller_Front class in the Zend framework and there it
complains that $_instance has not been declared, even though you can
see the declaration a couple of lines above.
So, even though is seems it is not the full issue, it seems to be
strongly related. In any case, one would say that reflection in
Quercus is broken, right?
Tested using Resin 3.1.7a and resin 3.2.1. Trying to use Zend in 3.2.1
I don't get the error I was showing above, but a blank page and no
error message anywhere.
S!
D.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus + Web Services / Zend
Well, moving forward
I've advanced a bit on the 3.2.1 front as the $_instance not defined
problem is no longer there, even if reflection is still broken. The
next issue I found is that accesing a stack, the isset(stack-{$name})
returns 1 (true) and then stack-{$name} returns false, where isset
is expected to return false directly as the object is not really
inside the stack. Not sure how that is supposed to work in PHP, but
Zend checked with isset() for existance, this failing.
This happens in Zend/Controller/Action/HelperBroker.pjp, line 232
Then I also found out PHP_EOL is not defined, which is not exactly a
bug, but Zend uses it, so I defined it not to get tons of PHP_EOL
all around :).
With those changes I was able to render the layout, but not content is
being displayed and, if I have to believe the traces, neither the
Controller or the View are being called.
This time I'm getting no error, trace or anything... Aren't
interpreted languages fun? :)
S!
D.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus + Web Services / Zend
Hi Adriano,
Thanks for your answer. I'm trying with the latest release of Zend,
(1.6.2) fresh from their site.
I follow their quickstart guide, substituting the Apache .htaccess
file with the URLRewrite filter to redirect all requests to
WEB-INF/php/public/index.php, storing the Zend framework in
WEB-INF/php/library/Zend and creating the
WEB-INF/php/application/bootstrap.php file the instructions mandate.
If using Resin 3.1.5, accessing the application raises a
***
Fatal Error: 'Array' is an unknown function. [spl_autoload_register]
***
but that's a well-know bug of Quercus in 3.1.5, fixed in 3.1.7.
I then try with 3.1.7a and I get these errors:
***
...bootstrap.php:16: Fatal Error: Zend_Controller_Front::$_instance is
an undeclared static property
An exception occured while bootstrapping the application.
...bootstrap.php:16: Fatal Error: Zend_Controller_Front::$_instance is
an undeclared static property
Stack Trace:
***
As I used copy/paste and I used the same files in a MAMP environment
some days ago, I thought it might be a Quercus thing, but I could not
find anything about it.
I can send you my setup if you wish, but I just followed the steps in
the quickstart guide, copy/pasting the content of index.php and
bootstrap.php.
Regarding the simple NuSOAP test, I include the library and try one of
the samples that issues something like:
***
...
$client = new
soapclient('http://www.scottnichol.com/samples/hellowsdl3.wsdl',
true,$proxyhost, $proxyport, $proxyusername, $proxypassword);
...
***
And always in these lines I get Server failed to send headers, even
though if I try accessing the WSDL files with my browser, I can see
them normally. The debug trace claims that the answer returned an
empty answer... but they are answering the browser so...
Thanks for your help,
S!
D.
Adriano Bonat [EMAIL PROTECTED] ha escrito:
Hello Daniel,
I had success running my project that uses ZF 1.5.2 on top of Quercus,
as it is using PDO, and the Quercus support at that time (dunno know,
I'm not watching its progress) didn't implement some necessary things,
I did implement and so it worked fine.
Which version of ZF were you using? Share your basic test too, so we
can try to figure out what is happening.
Regards,
-Adriano
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus PHP for TCP Servers?
Hi, To migrate the C++ daemon, Resin includes some utilities to run tasks (Java classes in the end) periodically, we have also used Open Symphony's Quartz scheduler to develop such thing in a container independent way. The benefit of it is that you don't have to care about two different pieces of software. OTOH, if you have to have the server running independently of the servlet container, then a Java application running as a service daemon would do fine. Regarding using PHP for the business logic, the approach we have experimented with is to call the Quercus engine through the Java Scripting Interface and return XML from that, which is then fed to FreeMarker/XSLT to generate the output. We have not developed it specifically for PHP, it works with any scripting language, but PHP is just fine if you have PHP resources and want to re-use them. One could use PHP directly through the Quercus servlet, but that would mean no SoC, and we want it. We have a mini-example application that uses it and the framework that does the work is also Open Source, in case you wanted to have a look at it and see how it's done. We had no PHP resources so we are not currently using the language itself, but we use it with Groovy and it is conceptually the same. BTW: There's a memory leak in version 3.1.5/6 when Quercus is called through the Java Scripting API, so don't test the combination with that version. Not sure if the leak is still present in latest version as I had no time to test it yet. (http://bugs.caucho.com/view.php?id=2709) S! D. S'està citant Emil Ong [EMAIL PROTECTED]: On Thu, Sep 04, 2008 at 06:06:04PM +0200, Clemens Perz wrote: Hi Guys! I am playing around with Resin/Quercus now for a few days, trying to make one of my PHP applications work in this environment. It consists out of two parts, a traditional web frontend that I think I will get up and running with Resin. The other part is a TCP server, which I usually start through inetd or a daemon written in C++. All the logic for the server is pure PHP. Do you think I can port this to be controlled by a daemon/service written in Java and still have the logic in PHP, processed by Quercus? Could you give me any hints how to approach this? Where could be pitfalls, what kind of wrappers you think I might have to write? Any information that helps would be highly welcome :)) Hi Clemens, This can be done in Resin, but it will take a bit of work. First, you'll need write a custom protocol. Resin has a facility that lets you do that and configure it pretty easily: http://www.caucho.com/resin/examples/custom-protocol/index.xtp Next, you'll need to integrate Quercus into that protocol. There are a couple ways of doing that, but the easiest would probably be to use the javax.script interface. You'll just use the Quercus engine for the language. Looks like we don't have an example up for that yet, so I'll throw a quick one up on the blog (http://blog.caucho.com/) later today. If you have experience with javax.script though, it should be pretty straight forward. Keep us updated on your progress! It sounds like a very interesting project. Emil Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:[EMAIL PROTECTED] http://blog.caucho.com/ Caucho: Reliable Open Source -- Resin: application server -- Quercus: PHP in Java -- Hessian Web Services ___ 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] Configuring a JNDI javax.mail.Session for a TLS SMTP server (gmail) (3.1.5)
Hi there, I'm trying to configure an application, JIRA, to send notification through a mail server, gmail, and for that I have to define a JNDI resource with all the data to be able to connect to the SMTP server. However, the problem is that the gmail SMTP server requires TLS and I've been unable to find out how to configure the resource so it connects appropriately. After a bit of searching, I came up with this configuration as a starter: --- mail uri=properties:mail.smtp.starttls.enable=true jndi-namemail/SecureSMTP/jndi-name smtp-hostsmtp.gmail.com/smtp-host smtp-port587/smtp-port smtp-ssltrue/smtp-ssl smtp-userusername/smtp-user transport-protocolsmtps/transport-protocol /mail --- However, all I get is: --- com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first. --- Which I believe is caused by the uri:properties being ignored or something similar. I also tried with: -- mail uri=properties:mail.smtp.starttls.enable=true;mail.smtp.auth=true -- In case it is not working due to mail.smtp.auth missing, but I'm not sure that is the correct way of specifying two properties. Documentation is kind of scarce in this area. I could not find any example of using a mail JNDI resource in resin to connect to a TLS smtp server. I found some examples using Tomcat, but of course the configuration is different (thanks lovely spec.). Is it possible at all? Cheers! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug when using thirdparty persistence layer with @PersistenceUnit
Hi,
You will probably need to specify which version of Resin 3.1.X you are
using, as things have changed greatly during the last versions.
This week I've been playing with JPA and using different providers
inside Resin, and I had to resort to 3.1.5 (I jumped from 3.1.2).
However, I'm using PERSISTENCE_LOCAL (We manage the
EntityManager/Factory ourselves) so I'm not sure how the IoC works.
Good luck!
D.
S'està citant wesley [EMAIL PROTECTED]:
Hi Scott,
I've expierenced a wired problen using @PersistenceUnit.
===Not functional!
@Component
public class PersistenceStrategy {
// @PersistenceContext(unitName = myunit)
// EntityManager em;
@PersistenceUnit(unitName = myunit)
EntityManagerFactory emf;
... // using emf, resin said
// com.mycompany.PersistenceStrategy.emf: @PersistenceUnit(unitName='myunit')
// is an unknown persistence unit.
// No matching JPA persistence-units have been deployed
}
=OK=
@Component
public class PersistenceStrategy {
@PersistenceContext(unitName = myunit)
EntityManager em;
@PersistenceUnit(unitName = myunit)
EntityManagerFactory emf;
... // using emf, just leaving em unused
}
I'm use Hibernate 3.2 as my persistence layer, with 3.1.s080304 snapshot.
Other configurations were normal and simple, as
http://wiki.caucho.com/Hibernate recommended.
Regards
- Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 2008-02-11 snapshot
That sounds great! That's most of what our current shell scripts do, so I'll be able to reduce them to an alias od run resin with that specific conf file with the command I pass to you. Nice! D. S'està citant Scott Ferguson [EMAIL PROTECTED]: On Feb 12, 2008, at 11:10 PM, Daniel López wrote: Regarding your explanation, Scott, that makes sense as I usually try to stop the instance normally, and just after that, if the process is still alive I kill it manually. It might happen that if the JVM is in the process of stopping itself but it takes too long, I kill it in the middle of the stop action... would that help to explain the watchdog stop process to fail and the inconsistent state? Yes. The next snapshot will give you a way to get out of that situation (probably tomorrow). 1) There's a new kill command, java -jar lib/resin.jar kill, which detaches the task from inside the watchdog and also kills the process (currently using the Process.destroy(). For Resin-Pro, it might be possible to add kill -9 at some point.) In your case, where you've killed the broken Resin instance with kill -9, the kill command will force the process detachment from the watchdog-manager, i.e. it will let you start a new instance even if the original stop thread gets stuck. 2) There's a new status command, java -jar lib/resin.jar status which will tell you the current state of the watchdog-manager and help debugging. 3) The watchdog instances are now registered with JMX. So you can use jconsole to hunt down the problem. 4) Most importantly, the watchdog has been refactored considerably. Specifically, the number of objects/fields changing on a start/stop has been reduced to essentially a single field/task. So there's much less opportunity for anything to go wrong. The docs will be in http://caucho.com/resin/doc/resin-watchdog.xtp. It's a bit sketchy at the moment, but several watchdog examples that should help people configuring it. -- Scott S! D. ___ 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] Resin 3.1 independent instances
Would then be the recommended way to work to set all watchdog ports on all resin.conf files to be the same one? I'm thinking that might be causing some of the issues as side effect. I understand the reason to use a well-known port, but sometimes the instances stop responding due to some application misbehaving (in our case, usually a DB breaks connections the wrong way and ends up blocking the JVM) and that's the time to kill the process manually. We have some scripts to check the status of the OS processes as sometimes the applications themselves, as bad patients, are not reliable on answering about their status :). Having an option to hard-kill instances have been proven very useful through the years, with this or any long lived processes. It's not an issue specific to Resin or any other server. My only issue was the watchdog process reporting instances to be up when they were not, as this woud mean it would not startup the new instance. So thanks for creating the bug reports, I'll keep an eyem on them to upgrade again. S! D. So my question would be... is there any configuration setting I can use with 3.1 to have several instances totally independent, so I can start/stop/kill one of them without affecting the rest? Unfortunately, sharing ONE resin.conf file is not an option and using ONE instance is not an option as well. That's the purpose of the watchdog-port. The start/stop program needs a well-known port so it can tell the instance to shut down. The old 3.0 method used pid files to handle the same situation. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator [SOLVED]
Hi Mattias,
Checking again, the method you mention did not work for me because it
is calling the PasswordDigest method that specifies the username and
password but not the realm, so it was using the default realm -
getting a different encription. I tried providing an empty realm but
that just reverted to the default.
However looking at the code, it seems that in order to be able to use
the method with an empty realm, one needs to specify a realm but use
none as name. So if you pass no value, you get a default but if you
pass a value, you can make it use null... a bit convoluted, I would
say :).
So one could use your class and specify none as realm or use mine,
both should work. I tested it on 3.1.1
Thx.
S!
Mattias Jiderhamn [EMAIL PROTECTED] ha escrito:
Daniel Lopez wrote (2007-10-29 18:19):
I'd like to confirm that this strategy works (with a tiny detail I
will explain) and I have now an application that is able to
authenticate through the container in Resin and Tomcat.
The only detail I had to modify is that wherever it reads:
return super.getPasswordDigest(...
it should read
return super.getPasswordDigest().getPasswordDigest(...
The reason being that the class that really performs the encrypting is
not the authenticator itself but a utility class called PasswordDigest
that can be accessed through getPasswordDigest().
Just for the record: The
com.caucho.server.security.AbstractAuthenticator has an overloaded
getPasswordDigest() that does just that:
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response,
ServletContext app,
String user, String password)
throws ServletException
{
if (_passwordDigest != null)
return _passwordDigest.getPasswordDigest(request, response, app,
user, password);
else
return password;
}
So I still claim the code below is sufficient (at least for Resin 3.0).
Anyway, glad I could help.
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator [SOLVED]
Hi,
It took me a while because I was busy with other things but for the
benefit of future generations, I'd like to confirm that this strategy
works (with a tiny detail I will explain) and I have now an
application that is able to authenticate through the container in
Resin and Tomcat.
The only detail I had to modify is that wherever it reads:
return super.getPasswordDigest(...
it should read
return super.getPasswordDigest().getPasswordDigest(...
The reason being that the class that really performs the encrypting is
not the authenticator itself but a utility class called PasswordDigest
that can be accessed through getPasswordDigest(). The weird choice
of names in this case (methods and class names equal) is surely
going to confuse people, as it did to me at the beginning.
Thanks again, Mattias.
D.
S'està citant Daniel López [EMAIL PROTECTED]:
Thanks Mattias,
I had thought about the subclassing option, but I had to try to see if
there was some configuration option I had missed :). In any case, that
will work fine, I believe. I'll be out of town for a week but when I go
back I'll give it a go and let you know how it worked.
Thanks again,
D.
Mattias Jiderhamn escribió:
You could probably implement your own authenticator, possibly just
subclassing the JdbcAuthenticator (see below), then use that
authenticator in resin-web.xml.
I myself wrote a patch for a Tomcat only webapp, that contains this
plus dummy implementations of Tomcat classes/interfaces like
org.apache.catalina.Container, Engine, Host, Realm, Server.
Maybe this code suites your needs too:
public class MyJdbcAuthenticator extends JdbcAuthenticator {
public MyJdbcAuthenticator() {
super.setPasswordDigestRealm(null);
}
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response, ServletContext app, String user, String
password) throws ServletException {
return super.getPasswordDigest(request, response, app, null, password);
}
public String getPasswordDigest(String password) throws ServletException {
return super.getPasswordDigest(null, null, null, null, password);
}
}
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin/Tomcat Common Authenticator
Hi all, Long story short: I started consulting in a company that is developing a product using Tomcat. They want to be able to run the application in different containers to make sure they are spec compliant and all, so I suggested Resin as an alternative. I've been able to configure the datasources, massage the web.xml to be more compliant etc. but now I came across a problem I'm not sure how easy it is to solve: the authenticator. Both containers have an implementation of a typical jdbc authenticator... but for a tiny detail: Resin uses username+realm+password for the digest and Tomcat uses just the password, hence the digests do not match and all password are considered wrong in one of the containers. The passwords in use are already stored like that and changing them would not really solve the problem but move it to the Tomcat side. I don't use container based authentication in my own applications for this very reason, but they are using it and I thought that might not be an uncommon problem so... is there any way to configure com.caucho.server.security.JdbcAuthenticator to use just the password for the digests? Cheers! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Fwd: Re: Security Manager
If Resin/Your application is starting without problems and you have nothing granted in your policy file, then it is sure the policy is not being applied :). We have one of our nodes configured in a similar manner and you have, at the very minimum, to grant permissions to the Caucho classes to allow Resin to open ports, write to temporary directories etc. so if Resin is starting without that, no policy is being applied. I'm out of the office and I have no way to get to that policy file now from my holidays place, but first of all you will need to get the policy file to be applied. We were using a previous version of Resin where the policy file could be specified as a startup parameter for http.sh, but AFAIK it is no longer possible with recent versions of Resin so you'll have to find out how to do it with the latest versions. S! D. S'està citant Mktg. Incorporate Fast [EMAIL PROTECTED]: Hello, I am trying to implement resin as an ISP for many hosts in a shared environment. We are setting up resin to run with a separate JVM per host and we hope to use the security manager to restrict server rights per user. 1.) We want to prohibit users from reading system files. 2.) We want to prohibit malicious attacks via java, i.e. system.exit(); I have included security-manager/ with the resin.conf file and we are using jvm-arg-Djava.security.policy=file:/mypolicy/resin.policy/jvm-arg. When the system restarts, it does not appear that it is using the policy file that we specified. After restart a JSP page is still able to read all files on server and execute system.exit. Can anybody please help me to identify what I am missing. Lastly the resin.policy file does not have anything granted. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 3.0.2x Quercus/Scripting Engine and Java 6 scripting issues
Hi there, I'm extending our home-made framework to be able to take advantage of Java 6 scripting capabilities, and I have found some issues with Quercus/Scripting Engine due to the way the scripting works in Java 6. In short, I developed the scripting module this morning in my office, using an older version of Resin, and all seemed to work fine (tests done with Rhino and Groovy), but then I went home to keep working there with Resin 3.0.21. All of sudden, I was unable to execute any script more than once and the error was being generated by Quercus, even though I was not trying to execute PHP. To make a long story short, after playing with the sources and some search I found out that the problem was the was scripting works and bug 1473 http://bugs.caucho.com/view.php?id=1473 which has been fixed in version 3.1. However, just having the conflicting files in the classpath in version 3.2X can break scripting with other engines in a Resin 3.2.0X, as all engines can to be queried when you tried to find one engine, so I was wondering whether back porting those changes was worthwhile. Otherwise, users of version 3.0.2X might encounter the problem even when trying to use other scripting engines, and even migrating from older versions of Resin. As I believe version 3.1 changed quite a bit, some users might try to migrate first to 3.0.2X and then... So, just a warning that it's not just the Quercus engine not being able to be used but causing conflicts also, just by being in the classpath. On a related note, I noticed the Quercus Scripting engine is not Invocable, are there any plans to implement this feature? I tested other engines (Rhino, Groovy, Jython) and Quercus was the only one not Invocable. Just wondering as that might mean I would also need to allow scripts to be just called using eval instead of eval+invoke, which suits me better, if I wanted to support Quercus. Cheers! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Which webapp is misbehaving?
Hi, Not sure if that would help, but what we do is to have various resin instances with the applications distributed among them, and then use mod_proxy instead of mod_caucho to forward requests. It's easier then to pinpoint the applications having problems, as you can see the process eating all the memory and move web applications between hosts until you find the bad boy. On the other hand, if you are having problems with mod_caucho, that would simply side step the issue, so it won't help diagnosing it. S! John Steel wrote: RH Fed 3/Resin 3.0.23 Pro There are about 30 webapps, spread across several virtual hosts on one of our servers using resin/Apache (mod_caucho). After about a days uptime, all Linux Swap is used and the server grids to a halt. A reboot is needed. If one of the webapps is playing naughty with memory, are there any tools/tricks available to see which one please? Its this - reported Jan 2005! http://caucho.rz.klopotek.de/support/resin-interest/0501/.html As it was dying, I managed to issue service httpd restart (i.e. restart apache, I left resin alone) and it recovered fine, where top previously showed all swap used it then showed most free. I turn on logging to finer as suggested but don't really know what to look for in all that verbosity. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] EJB and Resin 3.1
Do you mean simply having a web application as a place where you deploy your EJBs that are then accessed from other web applications? Or do you mean simply not packaging your web application as an .ear/.war file and still have your EJBs deployed? For the latter case, I don't use .war/.ear files for deployment and I don't remember this being a problem when I used to use EJB with Resin. For the first... the only problem I could think of would be if your application was not set up to start automatically when the server starts, as it could be waiting for the first web access to start the web context. I'm not sure if an EJB call would have the same effect, I don't think so. In any case, one of the first hurdles when deploying EJB is actually finding them in the JNDI tree, so it might be a problem of simply not looking under a wrong name. I used to have a test.jsp page that simply crawled the JNDI tree, it was useful to debug such kind of problems as JNDI does not answer you you almost got it!, so an extra 'jdb/', 'ejb' in your lookup name could be simply your problem. I don't have it here at the moment, but it is quite simple to create such a page, simply to crawl the JNDI tree. Good luck! D. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, is it possible to create EJBs packaged in a JAR file and have them available without creating a WAR file and a servlet to access them? Are there any examples on this? I see in the server logfile that my EJBs are compiled, but I get a NamingException when trying to access the from JNDI (from local scope, e.g. packaged in an EAR file). Thanks in advance Markus Wolf - -- NMMN - New Media Markets Networks http://www.nmmn.com/ Langbehnstrasse 6 22761 Hamburg Tel. 040 284 118 - 720 Fax 040 284 118 - 999 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFeXJiDBHISU1oEKERAh2zAJ4r9hI3RAuidG77BgqvysiYJmnSgwCfShVR DXumVHlx44Iy2qmkoWvw+Ns= =slki -END PGP SIGNATURE- ___ 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
