You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by ji...@codehaus.org on 2003/12/21 23:51:39 UTC
[jira] Created: (GERONIMO-132) Adds deployments based on their modification time
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-132
Here is an overview of the issue:
---------------------------------------------------------------------
Key: GERONIMO-132
Summary: Adds deployments based on their modification time
Type: Improvement
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Apache Geronimo
Components:
core
Assignee:
Reporter: Jacek Laskowski
Created: Sun, 21 Dec 2003 4:50 PM
Updated: Sun, 21 Dec 2003 4:50 PM
Description:
The coming patch modifies o.a.g.kernel.deployment.scanner.FileSystemScanner so that it only adds a file or directory when its modification time equals to or is greater then the time of the last scan
Added class' javadoc
NOTE: The class informs about its work's status. It may be appropriate to reflect this in log4j.properties by rising its threshold to DEBUG or INFO.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: JCA and Drools
Posted by Chris Perrin <cp...@hifiit.com>.
>--I'll tell you whatever you want to know about MBeans if you help me out
with Drools.
Sounds like a plan. I am not currently on the codehaus IRC, but I can be.
I'll get on there tonight... What time zone are you in?
Chris
----- Original Message -----
From: "n. alex rupp" <ru...@umn.edu>
To: <ge...@incubator.apache.org>
Sent: Friday, January 02, 2004 10:44 AM
Subject: Re: JCA and Drools
> Chris,
>
> I'm just about to start integrating Drools into the workflow engine for
Shocks.
> I tell you what--I'll tell you whatever you want to know about MBeans if
you
> help me out with Drools.
>
> Do you hang out on the codehaus irc? We could talk there...
>
> Cheers,
> --
> N. Alex Rupp
>
>
>
>
>
> ----- Original Message -----
> From: "Chris Perrin" <cp...@hifiit.com>
> To: <ge...@incubator.apache.org>
> Sent: Tuesday, December 23, 2003 11:42 AM
> Subject: Re: JCA and Drools
>
>
> > <whimper/>
> >
> > Right-o. Thanks David, that gives me a starting point, yet begs another
> > question and one I think I know the answer to. Would your recommend
going
> > the MBean route with Drools?
> >
> > The one thing that has kept me from implementing Drools as an MBean is
that
> > there was talk about having Geronimo itself use Drools to help run
itself
> > and I've never written an MBean for anything other than access by client
> > code.
> >
> > Chris
> >
> >
>
Re: JCA and Drools
Posted by "n. alex rupp" <ru...@umn.edu>.
Chris,
I'm just about to start integrating Drools into the workflow engine for Shocks.
I tell you what--I'll tell you whatever you want to know about MBeans if you
help me out with Drools.
Do you hang out on the codehaus irc? We could talk there...
Cheers,
--
N. Alex Rupp
----- Original Message -----
From: "Chris Perrin" <cp...@hifiit.com>
To: <ge...@incubator.apache.org>
Sent: Tuesday, December 23, 2003 11:42 AM
Subject: Re: JCA and Drools
> <whimper/>
>
> Right-o. Thanks David, that gives me a starting point, yet begs another
> question and one I think I know the answer to. Would your recommend going
> the MBean route with Drools?
>
> The one thing that has kept me from implementing Drools as an MBean is that
> there was talk about having Geronimo itself use Drools to help run itself
> and I've never written an MBean for anything other than access by client
> code.
>
> Chris
>
>
Re: JCA and Drools
Posted by David Jencks <da...@coredevelopers.net>.
I've now actually looked at jsr94 and drools a bit and think that there
is no reason whatsoever to implement a jca adapter for drools, at least
not for use in geronimo. The only effects would be to slow everything
down. Before actually reading the spec I had formed the idea that it
required access through a jca adapter: since it doesn't, lets not do it
that way.
Instead, I now think that the best way to deploy in geronimo is to wrap
drools in a (geronimo) mbean with a method getRulesRuntime that returns
the Drools RulesRuntime implementation. This can be bound directly
into a ReadOnlyContext for an ejb or servlet just as jca adapters are
using the "jmx" context.
Something similar could be done for the administration interface.
Sorry for the misleading commens earlier,
I'm happy to supply more advice on request.
thanks
david jencks
On Tuesday, December 23, 2003, at 10:02 AM, David Jencks wrote:
>
> On Tuesday, December 23, 2003, at 09:42 AM, Chris Perrin wrote:
>
>> <whimper/>
>>
>> Right-o. Thanks David, that gives me a starting point, yet begs
>> another
>> question and one I think I know the answer to. Would your recommend
>> going
>> the MBean route with Drools?
>
> Well, I think that whatever the problems might be, Drools needs a
> jsr94 interface, so I think that is a good place to start.
>
> On the other hand, you can probably simply deploy an appropriate
> drools object as a GeronimoMBean simply by writing a descriptor for
> it. The question is then, however, what components will use it and
> how, and how will the transaction and security contexts get
> propagated. Although the jca framework's answers to these questions
> don't make complete sense to me in the context of a rule engine, at
> least they provide some answer.
>
> I haven't looked into jsr94 enough to be able to comment on this any
> more intelligently yet.
>
> david jencks
>
>
>>
>> The one thing that has kept me from implementing Drools as an MBean
>> is that
>> there was talk about having Geronimo itself use Drools to help run
>> itself
>> and I've never written an MBean for anything other than access by
>> client
>> code.
>>
>> Chris
>>
>
Re: JCA and Drools
Posted by David Jencks <da...@coredevelopers.net>.
On Tuesday, December 23, 2003, at 09:42 AM, Chris Perrin wrote:
> <whimper/>
>
> Right-o. Thanks David, that gives me a starting point, yet begs
> another
> question and one I think I know the answer to. Would your recommend
> going
> the MBean route with Drools?
Well, I think that whatever the problems might be, Drools needs a jsr94
interface, so I think that is a good place to start.
On the other hand, you can probably simply deploy an appropriate drools
object as a GeronimoMBean simply by writing a descriptor for it. The
question is then, however, what components will use it and how, and how
will the transaction and security contexts get propagated. Although the
jca framework's answers to these questions don't make complete sense to
me in the context of a rule engine, at least they provide some answer.
I haven't looked into jsr94 enough to be able to comment on this any
more intelligently yet.
david jencks
>
> The one thing that has kept me from implementing Drools as an MBean is
> that
> there was talk about having Geronimo itself use Drools to help run
> itself
> and I've never written an MBean for anything other than access by
> client
> code.
>
> Chris
>
Re: JCA and Drools
Posted by Chris Perrin <cp...@hifiit.com>.
<whimper/>
Right-o. Thanks David, that gives me a starting point, yet begs another
question and one I think I know the answer to. Would your recommend going
the MBean route with Drools?
The one thing that has kept me from implementing Drools as an MBean is that
there was talk about having Geronimo itself use Drools to help run itself
and I've never written an MBean for anything other than access by client
code.
Chris
Re: JCA and Drools
Posted by David Jencks <da...@coredevelopers.net>.
I looked, there is essentially no jca implementation, just a couple of
do-nothing interface implementations.
My previous experiences with integrating a rules engine in JBoss made
me think that a jca interface for an in-vm rules engine was not a very
good fit, so I would expect some fairly severe conceptual mismatches to
appear shortly.
You have to figure out what a "physical connection" might correspond to
in Drools. My guess is that it corresponds to an instance of the rules
set. With luck these can be sensibly pooled when not in use. Your
ManagedConnection object would subclass or wrap the "physical
connection".
Then you have to figure out what the application level interface to
this is. Most likely this is specified by jsr94. This will be the
connection you get from the connection factory. The connection needs a
pointer to the managed connection object and should delegate any actual
work to the managed connection object.
I just remembered that I have a mock adapter for testing the geronimo
jca framework sitting here, so I will commit it: it may provide a
simpler guide to what is needed since there is no pesky backend to get
in the way.
Ask if you have more questions
thanks
david jencks
On Tuesday, December 23, 2003, at 08:58 AM, Chris Perrin wrote:
> David,
>
> If you can point me in the right direction, I am hoping to get some
> work on
> Geronimo done over the holidays.
>
> Chris
> ----- Original Message -----
> From: "David Jencks" <da...@coredevelopers.net>
> To: <ge...@incubator.apache.org>
> Sent: Tuesday, December 23, 2003 10:55 AM
> Subject: Re: JCA and Drools
>
>
>> Writing a JCA adapter is not all that difficult once you understand
>> what the different pieces are supposed to do. If they have classes
>> implementing ManagedConnectionFactory and ManagedConnection and an
>> ra.xml it might be complete.
>>
>> OpenEJB (non-NOVA) has a simple jdbc wrapper. JBoss has jdbc wrappers
>> and a jms wrapper, and in jboss patches you can find a jini wrapper I
>> wrote a long time ago. I'll also see if I can find a few minutes to
>> look at Drools.
>>
>> thanks
>> david jencks
>>
>> On Tuesday, December 23, 2003, at 08:42 AM, Chris Perrin wrote:
>>
>>> Group,
>>>
>>> Either JCA is a lot simpler to blend into Drools or I am missing the
>>> boat
>>> entirely. I've been looking over the JCA implementation already
>>> there
>>> and
>>> all it does is create a few Drools objects.
>>>
>>> Can someone point me to a JCA implementation inside Geronimo?
>>> Perhaps
>>> a
>>> good resource on what is needed?
>>>
>>> Chris
>>>
>>
>
Re: JCA and Drools
Posted by Chris Perrin <cp...@hifiit.com>.
David,
If you can point me in the right direction, I am hoping to get some work on
Geronimo done over the holidays.
Chris
----- Original Message -----
From: "David Jencks" <da...@coredevelopers.net>
To: <ge...@incubator.apache.org>
Sent: Tuesday, December 23, 2003 10:55 AM
Subject: Re: JCA and Drools
> Writing a JCA adapter is not all that difficult once you understand
> what the different pieces are supposed to do. If they have classes
> implementing ManagedConnectionFactory and ManagedConnection and an
> ra.xml it might be complete.
>
> OpenEJB (non-NOVA) has a simple jdbc wrapper. JBoss has jdbc wrappers
> and a jms wrapper, and in jboss patches you can find a jini wrapper I
> wrote a long time ago. I'll also see if I can find a few minutes to
> look at Drools.
>
> thanks
> david jencks
>
> On Tuesday, December 23, 2003, at 08:42 AM, Chris Perrin wrote:
>
> > Group,
> >
> > Either JCA is a lot simpler to blend into Drools or I am missing the
> > boat
> > entirely. I've been looking over the JCA implementation already there
> > and
> > all it does is create a few Drools objects.
> >
> > Can someone point me to a JCA implementation inside Geronimo? Perhaps
> > a
> > good resource on what is needed?
> >
> > Chris
> >
>
Re: JCA and Drools
Posted by David Jencks <da...@coredevelopers.net>.
Writing a JCA adapter is not all that difficult once you understand
what the different pieces are supposed to do. If they have classes
implementing ManagedConnectionFactory and ManagedConnection and an
ra.xml it might be complete.
OpenEJB (non-NOVA) has a simple jdbc wrapper. JBoss has jdbc wrappers
and a jms wrapper, and in jboss patches you can find a jini wrapper I
wrote a long time ago. I'll also see if I can find a few minutes to
look at Drools.
thanks
david jencks
On Tuesday, December 23, 2003, at 08:42 AM, Chris Perrin wrote:
> Group,
>
> Either JCA is a lot simpler to blend into Drools or I am missing the
> boat
> entirely. I've been looking over the JCA implementation already there
> and
> all it does is create a few Drools objects.
>
> Can someone point me to a JCA implementation inside Geronimo? Perhaps
> a
> good resource on what is needed?
>
> Chris
>
JCA and Drools
Posted by Chris Perrin <cp...@hifiit.com>.
Group,
Either JCA is a lot simpler to blend into Drools or I am missing the boat
entirely. I've been looking over the JCA implementation already there and
all it does is create a few Drools objects.
Can someone point me to a JCA implementation inside Geronimo? Perhaps a
good resource on what is needed?
Chris
Re: [jira] Created: (GERONIMO-132) Adds deployments based on their
modification time
Posted by Jacek Laskowski <ja...@hp.com>.
Hi Jeremy,
I like the comment. It seems it's not as easy as I initially thought.
Let me take a few moments more to think about it. I'll try to get an
overall picture of how the planners/scanner work.
In the meantime, do we close the issue in Jira with some status or leave
it open?
Jacek
Jeremy Boynes wrote:
> jira@codehaus.org wrote:
>
>
>> Description: The coming patch modifies
>> o.a.g.kernel.deployment.scanner.FileSystemScanner so that it only
>> adds a file or directory when its modification time equals to or is
>> greater then the time of the last scan
>>
>
> I had concerns with this approach during the initial implementation and
> felt that this was really the job of the Planners rather than the
> scanner - that the scanner should really just report all the currently
> located URLs.
>
> The first was ensuring this worked the same for all scanners, for all
> archive formats, and for packed/unpacked archives.
>
> To meet this requirement, this functionality would need to be
> implemented by all scanners - no only the File scanner this patch
> addresses, but also ones like the WebDAV URL scanner. This may be
> possible but does rely on the web server returning an accurate
> modification time; this could be worse if the webdav scanner tried to
> use the timestamp returned in the PROPFIND request. This might work, but
> was a concern.
>
> There is the question of just when the archive was modified. For a
> packed the modification of the archive itself might be good enough. For
> an unpacked archive though, the modification time of the root directory
> is not a good indicator - for example, adding a new JSP page to the root
> of a WAR would change the modification time of the directory triggering
> redeployment (which is not the desired effect). Also, as multiple files
> get copied into an unpacked archive then it may be inconsistent. I think
> a better solution is to watch the modification time of a specific file
> such as web.xml for a WAR or ejb-jar.xml for an EJB-JAR; however, this
> file will vary depending on the archive type.
>
> Some systems try to provide this by using two URLs - a deployment URL
> and a watch URL. I don't think building this into the scanner is a good
> solution - it is better performed by the planners.
>
> There is also the issue of dependencies between URLs - for example, a
> WAR may depend on an EJB-JAR so even though the WAR's URL has not been
> modified we need to redeploy it to allow for the new EJB-JAR version.
> Resolving these dependencies is the job of the Controller and planners.
>
> Given all that, my belief was that the job of the scanner should be kept
> real simple - return a list of currently known URLs and allow the
> Controller/Planners come up with a deployment plan.
>
> I look forward to other opinions but for now I would -1 this change.
>
Re: [jira] Created: (GERONIMO-132) Adds deployments based on their modification time
Posted by Dain Sundstrom <da...@coredevelopers.net>.
> The problem is with the DependencyService and scanner. When the
> scanner picks up a file it's handed over to a planner. The planner
> tries to deploy it and it succeeds, but see this:
>
> [java] 23:44:00,803 DEBUG [JettyWebApplication]
> jetty:role=WebApplication,
> uri="file:/c:/projects/geronimo/target/geronim
> o-DEV/deploy/jetty/geronimo-web-console.war" State changed from
> stopped to starting
> [java] 23:44:00,844 TRACE [DependencyService] Checking if parent
> is running: parent=jetty:role=WebContainer
> [java] 23:44:00,844 TRACE [DependencyService] Cannot run because
> parent is not running: parent=jetty:role=WebContainer
>
> which means that although the war was to have deployed, it simply
> failed as the dependency (WebContainer) was not up. The next time the
> scanner runs it won't pick up the war as the modification time hasn't
> changed since the last scan.
> It leds me to a conclusion that it may be a bug with the deployment as
> a file/directory may be deployed more than once to succeed if there's
> a dependency that is not started yet.
I just want to clear this one up. This is not a problem with the
deployment planner. The job of the deployment planner it bring a
deployment into the starting state, after that it is the component
should watch the system state and transition to running at the
appropriate time. The specific problem here is the WebContainer did
not transition to the running state, which means you need to look
somewhere else for the real problem.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [jira] Created: (GERONIMO-132) Adds deployments based on their
modification time
Posted by Jeremy Boynes <je...@coredevelopers.net>.
jira@codehaus.org wrote:
> Description: The coming patch modifies
> o.a.g.kernel.deployment.scanner.FileSystemScanner so that it only
> adds a file or directory when its modification time equals to or is
> greater then the time of the last scan
>
I had concerns with this approach during the initial implementation and
felt that this was really the job of the Planners rather than the
scanner - that the scanner should really just report all the currently
located URLs.
The first was ensuring this worked the same for all scanners, for all
archive formats, and for packed/unpacked archives.
To meet this requirement, this functionality would need to be
implemented by all scanners - no only the File scanner this patch
addresses, but also ones like the WebDAV URL scanner. This may be
possible but does rely on the web server returning an accurate
modification time; this could be worse if the webdav scanner tried to
use the timestamp returned in the PROPFIND request. This might work, but
was a concern.
There is the question of just when the archive was modified. For a
packed the modification of the archive itself might be good enough. For
an unpacked archive though, the modification time of the root directory
is not a good indicator - for example, adding a new JSP page to the root
of a WAR would change the modification time of the directory triggering
redeployment (which is not the desired effect). Also, as multiple files
get copied into an unpacked archive then it may be inconsistent. I think
a better solution is to watch the modification time of a specific file
such as web.xml for a WAR or ejb-jar.xml for an EJB-JAR; however, this
file will vary depending on the archive type.
Some systems try to provide this by using two URLs - a deployment URL
and a watch URL. I don't think building this into the scanner is a good
solution - it is better performed by the planners.
There is also the issue of dependencies between URLs - for example, a
WAR may depend on an EJB-JAR so even though the WAR's URL has not been
modified we need to redeploy it to allow for the new EJB-JAR version.
Resolving these dependencies is the job of the Controller and planners.
Given all that, my belief was that the job of the scanner should be kept
real simple - return a list of currently known URLs and allow the
Controller/Planners come up with a deployment plan.
I look forward to other opinions but for now I would -1 this change.
--
Jeremy