click

›

click-development

Deploy alternative

15 Messages

sabob

Deploy alternative

Reply Threaded

Hi all,

I have some code which implements
http://www.avoka.com/jira/browse/CLK-393.

In short XmlConfigService checks all jars under WEB-INF/lib for the
entry META-INF/web/* and copies them verbatim over to the application.
This takes care of both Control + Page resources.

To my mind this is much easier than manually specifying each resource
in Control#onDeploy and click.xml.

This was only scheduled for M3 but I needed it for the JQuery support
in ClickClick, which is resource intensive.

Can I check this in?

kind regards

bob

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

Ahmed Mohombe

Re: Deploy alternative

Reply Threaded

> I have some code which implements
> http://www.avoka.com/jira/browse/CLK-393.
Does this approach work on a wide range of Application Servers (with
different versions) and different settings?

> In short XmlConfigService checks all jars under WEB-INF/lib for the
> entry META-INF/web/* and copies them verbatim over to the application.
> This takes care of both Control + Page resources.
>
> To my mind this is much easier than manually specifying each resource
> in Control#onDeploy and click.xml.
This looks pretty like the "convention based" deployment I asked for a very very
long time ago (before #onDeploy was even introduced) :) .
AFAIK the reason against the convention based approach was that it was not working
on all widely used application servers (Malcolm knows more about this), hence
the explicit approach of #onDeploy was introduced.

> This was only scheduled for M3 but I needed it for the JQuery support
> in ClickClick, which is resource intensive.
> Can I check this in?
If it works, than I'm +1 for this, however I'm even more for "consistency":
so if this "convention" based approach is used, than it should be used all over
and *only* this one approach, so that users don't have to learn more things.

There are also a few things not clear to me:
#1 - what is the order of override for resources? Right now it's
determined by the order of controls specified in click.xml (and the referencing XML files with list
of controls). If the user extends a control, can simply override the resource only (without the need
to hack the click source).
In you approach, if you parse all jars in alphabetic order than there's no way to change the
override order?

#2 - doesn't the files (other than the standard) in MET-INF have "collateral" effects (on
performance or something else)?

#3 - what's the performance gain for "convention based deploy" vs. "explicit #onDeploy" ?

Ahmed.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

Malcolm Edgar-2

Re: Deploy alternative

Reply Threaded

Hi Guys,

The issue we had with previous attempts at a better resource
deployment strategy for other packaged controls was to search for
"/controls.xml" files in the class path, read the specified XML and
then auto-deploy resources. The problem here was that the Tomcat
classloader would create a lock on this descriptor XML file and the
containing JAR could never be deleted, and the application could never
be redeployed.

I spoke to an ex-Borland guy about this recently, and they had to
write a special classloader for the Borland app server to avoid JAR
locking. It introduced some inefficiency, but made auto deployment
work.

If we were to introduce this it would have to supplement the existing
stragegy. Click is at a point of maturity were we can remove existing
functionality without breaking lots of applications.

How does this relate to the modules concept?

regards Malcolm Edgar

On Fri, Jul 11, 2008 at 9:16 PM, Ahmed Mohombe <amohombe@...> wrote:

>> I have some code which implements
>> http://www.avoka.com/jira/browse/CLK-393.
> Does this approach work on a wide range of Application Servers (with
> different versions) and different settings?
>
>> In short XmlConfigService checks all jars under WEB-INF/lib for the
>> entry META-INF/web/* and copies them verbatim over to the application.
>> This takes care of both Control + Page resources.
>>
>> To my mind this is much easier than manually specifying each resource
>> in Control#onDeploy and click.xml.
> This looks pretty like the "convention based" deployment I asked for a very very
> long time ago (before #onDeploy was even introduced) :) .
> AFAIK the reason against the convention based approach was that it was not working
> on all widely used application servers (Malcolm knows more about this), hence
> the explicit approach of #onDeploy was introduced.
>
>> This was only scheduled for M3 but I needed it for the JQuery support
>> in ClickClick, which is resource intensive.
>> Can I check this in?
> If it works, than I'm +1 for this, however I'm even more for "consistency":
> so if this "convention" based approach is used, than it should be used all over
> and *only* this one approach, so that users don't have to learn more things.
>
> There are also a few things not clear to me:
> #1 - what is the order of override for resources? Right now it's
> determined by the order of controls specified in click.xml (and the referencing XML files with list
> of controls). If the user extends a control, can simply override the resource only (without the need
> to hack the click source).
> In you approach, if you parse all jars in alphabetic order than there's no way to change the
> override order?
>
> #2 - doesn't the files (other than the standard) in MET-INF have "collateral" effects (on
> performance or something else)?
>
> #3 - what's the performance gain for "convention based deploy" vs. "explicit #onDeploy" ?
>
>
> Ahmed.
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Click-development mailing list
> Click-development@...
> https://lists.sourceforge.net/lists/listinfo/click-development
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

Ahmed Mohombe

Re: Deploy alternative

Reply Threaded

> How does this relate to the modules concept?
The point #4 from the Module JIRA issue:

Modules packed as JARs also have resources to deploy, to ensure
the correct place of the resources (especially if they use
a different "root" than "/").

Ahmed.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

sabob

Re: Deploy alternative

Reply Threaded

In reply to this post by Ahmed Mohombe

Hi Ahmed,

Ahmed Mohombe wrote:
> Does this approach work on a wide range of Application Servers (with
> different versions) and different settings?

Well it should work on all Servlet containers. Here is the code:

Set jars = servletContext.getResourcePaths("/WEB-INF/lib");

If users specify jars outside this location, they have to use the
onDeploy I guess. It is also possible to deploy from the classpath but
that should be rare and is more difficult to cater for.

> This looks pretty like the "convention based" deployment I asked for a very very
> long time ago (before #onDeploy was even introduced) :) .
> AFAIK the reason against the convention based approach was that it was not working
> on all widely used application servers (Malcolm knows more about this), hence
> the explicit approach of #onDeploy was introduced.

I vaguely remember something like this. But the above should work on
all containers. I think deploying from the classpath is more difficult.

>
> There are also a few things not clear to me:
> #1 - what is the order of override for resources?

There is no order currently.

Right now it's
> determined by the order of controls specified in click.xml (and the referencing XML files with list
> of controls). If the user extends a control, can simply override the resource only (without the need
> to hack the click source).
> In you approach, if you parse all jars in alphabetic order than there's no way to change the
> override order?

Something can be built for ordering scenario's e.g. provide the order
to deploy jars.

>
> #2 - doesn't the files (other than the standard) in MET-INF have "collateral" effects (on
> performance or something else)?

The code just iterates the entries in the jar and checks for
'META-INF/web/*'. It does not touch the classes. As for performance I
don't have any numbers yet. But scanning through jars should not have
much effect on startup performance.

>
> #3 - what's the performance gain for "convention based deploy" vs. "explicit #onDeploy" ?

It depends on how many resources you deploy. The more resources is
deployed, the more the gain. I tested the deployment approach with
JQuery project in ClickClick and its much easier than manually listing
the resources and creating control.jar files and listing them in
click.xml.

kind regards

bob

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

sabob

Re: Deploy alternative

Reply Threaded

In reply to this post by Malcolm Edgar-2

Hi Malcolm,

Malcolm Edgar wrote:
>
> The issue we had with previous attempts at a better resource
> deployment strategy for other packaged controls was to search for
> "/controls.xml" files in the class path, read the specified XML and
> then auto-deploy resources. The problem here was that the Tomcat
> classloader would create a lock on this descriptor XML file and the
> containing JAR could never be deleted, and the application could never
> be redeployed.

Hmm I will double this.

>
> I spoke to an ex-Borland guy about this recently, and they had to
> write a special classloader for the Borland app server to avoid JAR
> locking. It introduced some inefficiency, but made auto deployment
> work.
>
> If we were to introduce this it would have to supplement the existing
> stragegy. Click is at a point of maturity were we can remove existing
> functionality without breaking lots of applications.

Don't think the two methods are complementary but no harm in leaving
Control#onDeploy as is.

>
> How does this relate to the modules concept?

The new deployment caters especially for modules as all resources,
Page and Controls can be copied verbatim as they were developed.

kind regards

bob

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

sabob

Re: Deploy alternative

Reply Threaded

In reply to this post by sabob

> It depends on how many resources you deploy. The more resources is
> deployed, the more the gain. I tested the deployment approach with
> JQuery project in ClickClick and its much easier than manually listing
> the resources and creating control.jar files and listing them in
> click.xml.

The above should be control.xml not control.jar...

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

sabob

Re: Deploy alternative

Reply Threaded

In reply to this post by sabob

Hi all,

I have checked the deployment in. Its not alot of code so please give
it a review.

Malcolm, I tested this with Tomcat and redeployment seems to work.
Perhaps there could be problems in a different environment.

kind regards

bob

bob wrote:

> Hi all,
>
> I have some code which implements
> http://www.avoka.com/jira/browse/CLK-393.
>
> In short XmlConfigService checks all jars under WEB-INF/lib for the
> entry META-INF/web/* and copies them verbatim over to the application.
> This takes care of both Control + Page resources.
>
> To my mind this is much easier than manually specifying each resource
> in Control#onDeploy and click.xml.
>
> This was only scheduled for M3 but I needed it for the JQuery support
> in ClickClick, which is resource intensive.
>
> Can I check this in?
>
> kind regards
>
> bob
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Malcolm Edgar-2

Re: Deploy alternative

Reply Threaded

This issue, replates back to this JIRA below:

http://www.avoka.com/jira/browse/CLK-82

I can recall which versions of Tomcat had this issue but it included
the 5.x series.

regards Malcolm Edgar

On Sat, Jul 12, 2008 at 12:22 AM, bob <sabob1@...> wrote:

> Hi all,
>
> I have checked the deployment in. Its not alot of code so please give
> it a review.
>
> Malcolm, I tested this with Tomcat and redeployment seems to work.
> Perhaps there could be problems in a different environment.
>
> kind regards
>
> bob
>
> bob wrote:
>> Hi all,
>>
>> I have some code which implements
>> http://www.avoka.com/jira/browse/CLK-393.
>>
>> In short XmlConfigService checks all jars under WEB-INF/lib for the
>> entry META-INF/web/* and copies them verbatim over to the application.
>> This takes care of both Control + Page resources.
>>
>> To my mind this is much easier than manually specifying each resource
>> in Control#onDeploy and click.xml.
>>
>> This was only scheduled for M3 but I needed it for the JQuery support
>> in ClickClick, which is resource intensive.
>>
>> Can I check this in?
>>
>> kind regards
>>
>> bob
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Click-development mailing list
> Click-development@...
> https://lists.sourceforge.net/lists/listinfo/click-development
>

Malcolm Edgar-2

Re: Deploy alternative

Reply Threaded

This implementation looks good

regards Malcolm Edgar

On Sat, Jul 12, 2008 at 6:53 PM, Malcolm Edgar <malcolm.edgar@...> wrote:

> This issue, replates back to this JIRA below:
>
> http://www.avoka.com/jira/browse/CLK-82
>
> I can recall which versions of Tomcat had this issue but it included
> the 5.x series.
>
> regards Malcolm Edgar
>
> On Sat, Jul 12, 2008 at 12:22 AM, bob <sabob1@...> wrote:
>> Hi all,
>>
>> I have checked the deployment in. Its not alot of code so please give
>> it a review.
>>
>> Malcolm, I tested this with Tomcat and redeployment seems to work.
>> Perhaps there could be problems in a different environment.
>>
>> kind regards
>>
>> bob
>>
>> bob wrote:
>>> Hi all,
>>>
>>> I have some code which implements
>>> http://www.avoka.com/jira/browse/CLK-393.
>>>
>>> In short XmlConfigService checks all jars under WEB-INF/lib for the
>>> entry META-INF/web/* and copies them verbatim over to the application.
>>> This takes care of both Control + Page resources.
>>>
>>> To my mind this is much easier than manually specifying each resource
>>> in Control#onDeploy and click.xml.
>>>
>>> This was only scheduled for M3 but I needed it for the JQuery support
>>> in ClickClick, which is resource intensive.
>>>
>>> Can I check this in?
>>>
>>> kind regards
>>>
>>> bob
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Click-development mailing list
>> Click-development@...
>> https://lists.sourceforge.net/lists/listinfo/click-development
>>
>

sabob

Re: Deploy alternative

Reply Threaded

Malcolm Edgar wrote:
> This implementation looks good

Been thinking about changing the implementation to query the classpath
instead of only WEB-INF/lib. This will address issues when Click jars
are placed in shared lib.

Will check if there are any locking issues with Tomcat.

>
> regards Malcolm Edgar
>
> On Sat, Jul 12, 2008 at 6:53 PM, Malcolm Edgar <malcolm.edgar@...> wrote:
>> This issue, replates back to this JIRA below:
>>
>> http://www.avoka.com/jira/browse/CLK-82
>>
>> I can recall which versions of Tomcat had this issue but it included
>> the 5.x series.
>>
>> regards Malcolm Edgar
>>
>> On Sat, Jul 12, 2008 at 12:22 AM, bob <sabob1@...> wrote:
>>> Hi all,
>>>
>>> I have checked the deployment in. Its not alot of code so please give
>>> it a review.
>>>
>>> Malcolm, I tested this with Tomcat and redeployment seems to work.
>>> Perhaps there could be problems in a different environment.
>>>
>>> kind regards
>>>
>>> bob
>>>
>>> bob wrote:
>>>> Hi all,
>>>>
>>>> I have some code which implements
>>>> http://www.avoka.com/jira/browse/CLK-393.
>>>>
>>>> In short XmlConfigService checks all jars under WEB-INF/lib for the
>>>> entry META-INF/web/* and copies them verbatim over to the application.
>>>> This takes care of both Control + Page resources.
>>>>
>>>> To my mind this is much easier than manually specifying each resource
>>>> in Control#onDeploy and click.xml.
>>>>
>>>> This was only scheduled for M3 but I needed it for the JQuery support
>>>> in ClickClick, which is resource intensive.
>>>>
>>>> Can I check this in?
>>>>
>>>> kind regards
>>>>
>>>> bob
>>>>
>>>> -------------------------------------------------------------------------
>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>> Studies have shown that voting for your favorite open source project,
>>>> along with a healthy diet, reduces your potential for chronic lameness
>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Click-development mailing list
>>> Click-development@...
>>> https://lists.sourceforge.net/lists/listinfo/click-development
>>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

Malcolm Edgar-2

Re: Deploy alternative

Reply Threaded

That may take a long time on app servers with lots of shared JARs.
Tomcat might not be so bad, but JBoss has a lot of shared JARS.

I dont think this is the right thing todo because modules should be
added to the web app explicitly, not shared across apps. I actually
don't recommend this shared click JARs approach, I think its nuts when
you are maintaining different applications.

regards Malcolm Edgar

On Thu, Aug 7, 2008 at 5:57 AM, Bob Schellink <sabob1@...> wrote:

> Malcolm Edgar wrote:
>> This implementation looks good
>
>
> Been thinking about changing the implementation to query the classpath
> instead of only WEB-INF/lib. This will address issues when Click jars
> are placed in shared lib.
>
> Will check if there are any locking issues with Tomcat.
>
>
>>
>> regards Malcolm Edgar
>>
>> On Sat, Jul 12, 2008 at 6:53 PM, Malcolm Edgar <malcolm.edgar@...> wrote:
>>> This issue, replates back to this JIRA below:
>>>
>>> http://www.avoka.com/jira/browse/CLK-82
>>>
>>> I can recall which versions of Tomcat had this issue but it included
>>> the 5.x series.
>>>
>>> regards Malcolm Edgar
>>>
>>> On Sat, Jul 12, 2008 at 12:22 AM, bob <sabob1@...> wrote:
>>>> Hi all,
>>>>
>>>> I have checked the deployment in. Its not alot of code so please give
>>>> it a review.
>>>>
>>>> Malcolm, I tested this with Tomcat and redeployment seems to work.
>>>> Perhaps there could be problems in a different environment.
>>>>
>>>> kind regards
>>>>
>>>> bob
>>>>
>>>> bob wrote:
>>>>> Hi all,
>>>>>
>>>>> I have some code which implements
>>>>> http://www.avoka.com/jira/browse/CLK-393.
>>>>>
>>>>> In short XmlConfigService checks all jars under WEB-INF/lib for the
>>>>> entry META-INF/web/* and copies them verbatim over to the application.
>>>>> This takes care of both Control + Page resources.
>>>>>
>>>>> To my mind this is much easier than manually specifying each resource
>>>>> in Control#onDeploy and click.xml.
>>>>>
>>>>> This was only scheduled for M3 but I needed it for the JQuery support
>>>>> in ClickClick, which is resource intensive.
>>>>>
>>>>> Can I check this in?
>>>>>
>>>>> kind regards
>>>>>
>>>>> bob
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>>> Studies have shown that voting for your favorite open source project,
>>>>> along with a healthy diet, reduces your potential for chronic lameness
>>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>>
>>>> -------------------------------------------------------------------------
>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>> Studies have shown that voting for your favorite open source project,
>>>> along with a healthy diet, reduces your potential for chronic lameness
>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>> _______________________________________________
>>>> Click-development mailing list
>>>> Click-development@...
>>>> https://lists.sourceforge.net/lists/listinfo/click-development
>>>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-development mailing list
> Click-development@...
> https://lists.sourceforge.net/lists/listinfo/click-development
>

sabob

Re: Deploy alternative

Reply Threaded

Hi Malcolm,

Malcolm Edgar wrote:
> That may take a long time on app servers with lots of shared JARs.
> Tomcat might not be so bad, but JBoss has a lot of shared JARS.

I use the following code:

Enumeration en = classLoader.getResources("META-INF/web");
while (en.hasMoreElements()) {
URL url = (URL) en.nextElement();
String path = url.getFile();
..
}

I think this will be faster than our current approach as only those
jars which contains the resource "META-INF/web" are scanned.

Do you forsee getResources will be an expensive operation?

> I dont think this is the right thing todo because modules should be
> added to the web app explicitly, not shared across apps. I actually
> don't recommend this shared click JARs approach, I think its nuts when
> you are maintaining different applications.

Nods its not the right approach at all. My thinking is that if we can
have an implementation from the classpath that is more efficient than
scanning WEB-INF/lib then folk can place the jars where ever they want
and Click will still work.

kind regards

bob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-development mailing list
Click-development@...
https://lists.sourceforge.net/lists/listinfo/click-development

sabob

Re: Deploy alternative

Reply Threaded

Bob Schellink wrote:
>
> I use the following code:
>
> Enumeration en = classLoader.getResources("META-INF/web");
> while (en.hasMoreElements()) {
> URL url = (URL) en.nextElement();
> String path = url.getFile();
> ..
> }

Did a quick perf test on Tomcat and JBoss (server -> all) with the
above code vs the current approach.

current approach: avg time to deploy files from jars = 640 ms
above approach: avg time to deploy files from jars = 235 ms

So using the classloader to get resources is certainly faster on both
jboss and tomcat.

Also note that I have not noticed any locking when reloading examples
using the above approach.

Whether we use the above approach or not its still good to know this
option works ;-)

>
> I think this will be faster than our current approach as only those
> jars which contains the resource "META-INF/web" are scanned.
>
> Do you forsee getResources will be an expensive operation?
>
>
>> I dont think this is the right thing todo because modules should be
>> added to the web app explicitly, not shared across apps. I actually
>> don't recommend this shared click JARs approach, I think its nuts when
>> you are maintaining different applications.
>
>
> Nods its not the right approach at all. My thinking is that if we can
> have an implementation from the classpath that is more efficient than
> scanning WEB-INF/lib then folk can place the jars where ever they want
> and Click will still work.
>
> kind regards
>
> bob
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/

Malcolm Edgar-2

Re: Deploy alternative