On 8/18/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> > On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Now that would be cool. I think we would have to load all clay config
> > > files
> > to resolve the inheritance dependencies but that would be way slick.
> > >
> >
> > Ye
> From: "Gary VanMatre" <[EMAIL PROTECTED]>
>
> > I believe that you can spawn threads in a J2EE web container.
> > The restriction is only within the EJB container. I'm not sure if
> > there are limitations in a portal but a client or applet J2EE container
> > doesn't have thread restrictions.
From: "Gary VanMatre" <[EMAIL PROTECTED]>
I believe that you can spawn threads in a J2EE web container.
The restriction is only within the EJB container. I'm not sure if
there are limitations in a portal but a client or applet J2EE container
doesn't have thread restrictions. Shale doesn't sup
> > From: Gary VanMatre said:
> > I was poking around in log4j and found a very similar feature
> > that allows you to configure a file watch dog for the
> > properties files.
>
> You can't use that within a J2EE container, however, because it spawns a
> watcher thread. This thread is then outs
> From: Gary VanMatre said:
> I was poking around in log4j and found a very similar feature
> that allows you to configure a file watch dog for the
> properties files.
You can't use that within a J2EE container, however, because it spawns a
watcher thread. This thread is then outside the lifecy
> On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Now that would be cool. I think we would have to load all clay config
> > files
> to resolve the inheritance dependencies but that would be way slick.
> >
>
> Yep, you'd need to reload the whole set. Plus, do it in a way that
On 7/29/05, Greg Reddin <[EMAIL PROTECTED]> wrote:
> On Jul 29, 2005, at 1:55 AM, Craig McClanahan wrote:
> > It's sort of a different way to look at it, but consider this ...
> > maybe the act of configuring the filter *is* your indication that you
> > want to check for reloads, and lack of the fi
On Jul 29, 2005, at 1:55 AM, Craig McClanahan wrote:
It's sort of a different way to look at it, but consider this ...
maybe the act of configuring the filter *is* your indication that you
want to check for reloads, and lack of the filter would work as things
do today (i.e. you have to reload the
On 7/28/05, Greg Reddin <[EMAIL PROTECTED]> wrote:
> On Jul 28, 2005, at 6:30 PM, David Geary wrote:
> > I'm not sure I like pulling Chain into Tiles standalone (we are
> > talking about writing a Chain Command in Tiles, right?). I would
> > prefer a POJO in Tiles that does the dirty work (Shale co
On Jul 28, 2005, at 6:30 PM, David Geary wrote:
I'm not sure I like pulling Chain into Tiles standalone (we are
talking about writing a Chain Command in Tiles, right?). I would
prefer a POJO in Tiles that does the dirty work (Shale could have a
Command wrapper that calls Tiles' POJO, if need be
"Craig McClanahan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Now that would be cool. I think we would have to load all clay config
files to resolve the inheritance dependencies but that would be way slick.
>
Yep, you'
Le 05-07-28 à 16:14, Greg Reddin a écrit :
[EMAIL PROTECTED] wrote:
On Jul 28, 2005, at 4:45 PM, [EMAIL PROTECTED] wrote:
The JSP-like approach would be more intrusive. The
DefinitionsFactory
would have to store the modified date of a definition and the
getDefinition() method would have
[EMAIL PROTECTED] wrote:
On Jul 28, 2005, at 4:45 PM, [EMAIL PROTECTED] wrote:
The JSP-like approach would be more intrusive. The DefinitionsFactory
would have to store the modified date of a definition and the
getDefinition() method would have to check the date against the date
of
the file
> On Jul 28, 2005, at 4:45 PM, [EMAIL PROTECTED] wrote:
> >> The JSP-like approach would be more intrusive. The DefinitionsFactory
> >> would have to store the modified date of a definition and the
> >> getDefinition() method would have to check the date against the date
> >> of
> >> the file and
On Jul 28, 2005, at 4:45 PM, [EMAIL PROTECTED] wrote:
The JSP-like approach would be more intrusive. The DefinitionsFactory
would have to store the modified date of a definition and the
getDefinition() method would have to check the date against the date
of
the file and reload if necessary.
> On Jul 28, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote:
> >> 1) How to trigger a reload()? Via a request to the servlet or some
> >> kind of API call, or a process that is "watching" the config files.
> >> Could maybe work like JSP, when you ask for a definition, the factory
> >> will look to see
On Jul 28, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote:
1) How to trigger a reload()? Via a request to the servlet or some
kind of API call, or a process that is "watching" the config files.
Could maybe work like JSP, when you ask for a definition, the factory
will look to see if it has changed.
> On Jul 28, 2005, at 11:51 AM, David Geary wrote:
> > I'll try to take a look next week to see what it'd take, but in the
> > meantime if
> > someone implements it out from under me, I won't feel bad. 8-)
>
> It looks like everything needed to load a DefinitionsFactory is
> available in Definit
On Jul 28, 2005, at 11:51 AM, David Geary wrote:
I'll try to take a look next week to see what it'd take, but in the
meantime if
someone implements it out from under me, I won't feel bad. 8-)
It looks like everything needed to load a DefinitionsFactory is
available in DefinitionsUtil. Right
> On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Now that would be cool. I think we would have to load all clay config
> > files
> to resolve the inheritance dependencies but that would be way slick.
> >
>
> Yep, you'd need to reload the whole set. Plus, do it in a way that
Le 05-07-28 à 10:45, Craig McClanahan a écrit :
On 7/28/05, Andy Freeman <[EMAIL PROTECTED]> wrote:
I would like to think that Tiles would be updated to work the same
way.
Yep ... definitely :-).
Anybody want to tackle building some patches for that one?
I'll try to take a look next
Le 05-07-28 à 10:35, Craig McClanahan a écrit :
On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Now that would be cool. I think we would have to load all clay
config files to resolve the inheritance dependencies but that
would be way slick.
Yep, you'd need to reload the who
On 7/28/05, Andy Freeman <[EMAIL PROTECTED]> wrote:
>
> I would like to think that Tiles would be updated to work the same way.
>
Yep ... definitely :-).
Anybody want to tackle building some patches for that one?
Craig
-
To u
On 7/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> For production deployment, it's likely that we would want the reload
> capability disabled (most of the IT guys I know would laugh me out of
> the room if I proposed to fix a typo in a running JSP page, on a live
> production app :-).
On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Now that would be cool. I think we would have to load all clay config files
> to resolve the inheritance dependencies but that would be way slick.
>
Yep, you'd need to reload the whole set. Plus, do it in a way that
does not require
> On 7/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Sergey,
> >
> > > Now, I have to restart my servlet container each time I have even small
> > > changes in the clay configuration file. I have not to do it for java
> > > classes, bundles, jsps. Development the UI with Clay might be mu
Gary,
I suggest this feature should be tranparant for developer like changes in
JSP when developer have just save the file. Currently, We are able to change
java code right in debug mode and those changes will apply immediately.
>From this perspective, the requirement to reload the configuration
On 7/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sergey,
>
> > Now, I have to restart my servlet container each time I have even small
> > changes in the clay configuration file. I have not to do it for java
> > classes, bundles, jsps. Development the UI with Clay might be much more
> >
Sergey,
> Now, I have to restart my servlet container each time I have even small
> changes in the clay configuration file. I have not to do it for java
> classes, bundles, jsps. Development the UI with Clay might be much more
> faster if clay config file will be updated on the fly.
> Does any
+1 ... just today I was describing to someone what Clay brought to the
table, and this was the very first question asked :-).
Craig
On 7/27/05, Sergey Smirnov <[EMAIL PROTECTED]> wrote:
> Now, I have to restart my servlet container each time I have even small
> changes in the clay configuration f
30 matches
Mail list logo
