beanshell server

[Adam Heath-2]

BeanShellContainer calls 'server(portNum)', which is a beanshell helper
method, that starts 2 servers, an  http and telnet server.  However,
there is no control over the threads that are created.  Can't set
daemon, priority, thread group, or implement some kind of cleanup wrapper.

I'd like to remove this poorly implemented feature by bsh; however, the
only way to do that is to not actually start the bsh server(s).  What do
others think?

[David E Jones-3]

This is a good question. Does anyone actually USE this? It's an  
interesting feature, but perhaps we should turn it off by default  
(leave it there, but commented out in the ofbiz-containers.xml file).

If any does use this, please speak up. If anyone doubts they will ever  
use this, also please speak up...

-David


On Dec 21, 2008, at 8:48 PM, Adam Heath wrote:

> BeanShellContainer calls 'server(portNum)', which is a beanshell  
> helper
> method, that starts 2 servers, an  http and telnet server.  However,
> there is no control over the threads that are created.  Can't set
> daemon, priority, thread group, or implement some kind of cleanup  
> wrapper.
>
> I'd like to remove this poorly implemented feature by bsh; however,  
> the
> only way to do that is to not actually start the bsh server(s).  
> What do
> others think?

[Adam Heath-2]

David E Jones wrote:
>
> This is a good question. Does anyone actually USE this? It's an
> interesting feature, but perhaps we should turn it off by default (leave
> it there, but commented out in the ofbiz-containers.xml file).
>
> If any does use this, please speak up. If anyone doubts they will ever
> use this, also please speak up...

As for the security restrictions(or severe lack there of, for this), we
tend to use standard jsp pages, that require normal login protection(and
the full support that ofbiz gives for that), to implement
'remote-control' of events.

If ofbiz is suppsoed to be a set of best practices, then this is *not*
one of them.  I vote for removing it, and *not* leaving it commented out.

[hans_bakker]

+1 : removed

On Mon, 2008-12-22 at 00:22 -0600, Adam Heath wrote:

> David E Jones wrote:
> >
> > This is a good question. Does anyone actually USE this? It's an
> > interesting feature, but perhaps we should turn it off by default (leave
> > it there, but commented out in the ofbiz-containers.xml file).
> >
> > If any does use this, please speak up. If anyone doubts they will ever
> > use this, also please speak up...
>
> As for the security restrictions(or severe lack there of, for this), we
> tend to use standard jsp pages, that require normal login protection(and
> the full support that ofbiz gives for that), to implement
> 'remote-control' of events.
>
> If ofbiz is suppsoed to be a set of best practices, then this is *not*
> one of them.  I vote for removing it, and *not* leaving it commented out.
>

--
Antwebsystems.com: Quality OFBiz services for competitive prices

[David E Jones-3]

On Dec 21, 2008, at 11:22 PM, Adam Heath wrote:

> David E Jones wrote:
>>
>> This is a good question. Does anyone actually USE this? It's an
>> interesting feature, but perhaps we should turn it off by default  
>> (leave
>> it there, but commented out in the ofbiz-containers.xml file).
>>
>> If any does use this, please speak up. If anyone doubts they will  
>> ever
>> use this, also please speak up...
>
> As for the security restrictions(or severe lack there of, for this),  
> we
> tend to use standard jsp pages, that require normal login  
> protection(and
> the full support that ofbiz gives for that), to implement
> 'remote-control' of events.
>
> If ofbiz is suppsoed to be a set of best practices, then this is *not*
> one of them.  I vote for removing it, and *not* leaving it commented  
> out.

Yes, well, as much as best practices is a priority, pragmatism is a  
higher one... especially in a world where one man's best practice is  
another man's nightmare (and since we are human we all need to  
remember that even if we are the first "man" in that sentence, the  
second "man" in the sentence may be us in the future).

On the pragmatic note, we can deprecate and remove things, but I  
generally don't like it if there is no replacement. Once an adequate  
replacement is in place that people like in general, THEN we can  
consider deprecation and removal.

Of course, if no one is using a certain feature, then we might as well  
toss it... hence my request for community feedback.

-David

[BJ Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I comment out both. But I always like the ability to have it.
I am just a trinket collector. hate to throw anything away.
:D

Adam Heath sent the following on 12/21/2008 7:48 PM:

> BeanShellContainer calls 'server(portNum)', which is a beanshell helper
> method, that starts 2 servers, an  http and telnet server.  However,
> there is no control over the threads that are created.  Can't set
> daemon, priority, thread group, or implement some kind of cleanup wrapper.
>
> I'd like to remove this poorly implemented feature by bsh; however, the
> only way to do that is to not actually start the bsh server(s).  What do
> others think?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJT2LUrP3NbaWWqE4RAve4AKCE5QazYwPk5LJSDBn+OZnisS5/AwCfSN6h
/w2YE43yYlGA4tTCiTxrmHo=
=fW/y
-----END PGP SIGNATURE-----

[Jacques Le Roux]

I'm not using it and I'd vote for commenting out. It's then oneself responsibility to use it or not
I know Si is an active user and he will not answer since he unsubscribed from this list

Jacques

From: "David E Jones" <[hidden email]>

>
> On Dec 21, 2008, at 11:22 PM, Adam Heath wrote:
>
>> David E Jones wrote:
>>>
>>> This is a good question. Does anyone actually USE this? It's an
>>> interesting feature, but perhaps we should turn it off by default  
>>> (leave
>>> it there, but commented out in the ofbiz-containers.xml file).
>>>
>>> If any does use this, please speak up. If anyone doubts they will  
>>> ever
>>> use this, also please speak up...
>>
>> As for the security restrictions(or severe lack there of, for this),  
>> we
>> tend to use standard jsp pages, that require normal login  
>> protection(and
>> the full support that ofbiz gives for that), to implement
>> 'remote-control' of events.
>>
>> If ofbiz is suppsoed to be a set of best practices, then this is *not*
>> one of them.  I vote for removing it, and *not* leaving it commented  
>> out.
>
> Yes, well, as much as best practices is a priority, pragmatism is a  
> higher one... especially in a world where one man's best practice is  
> another man's nightmare (and since we are human we all need to  
> remember that even if we are the first "man" in that sentence, the  
> second "man" in the sentence may be us in the future).
>
> On the pragmatic note, we can deprecate and remove things, but I  
> generally don't like it if there is no replacement. Once an adequate  
> replacement is in place that people like in general, THEN we can  
> consider deprecation and removal.
>
> Of course, if no one is using a certain feature, then we might as well  
> toss it... hence my request for community feedback.
>
> -David
>

[Daniel Martínez]

+1: commented
--
Daniel

David E Jones escribió:

>
> On Dec 21, 2008, at 11:22 PM, Adam Heath wrote:
>
>> David E Jones wrote:
>>>
>>> This is a good question. Does anyone actually USE this? It's an
>>> interesting feature, but perhaps we should turn it off by default
>>> (leave
>>> it there, but commented out in the ofbiz-containers.xml file).
>>>
>>> If any does use this, please speak up. If anyone doubts they will ever
>>> use this, also please speak up...
>>
>> As for the security restrictions(or severe lack there of, for this), we
>> tend to use standard jsp pages, that require normal login protection(and
>> the full support that ofbiz gives for that), to implement
>> 'remote-control' of events.
>>
>> If ofbiz is suppsoed to be a set of best practices, then this is *not*
>> one of them.  I vote for removing it, and *not* leaving it commented
>> out.
>
> Yes, well, as much as best practices is a priority, pragmatism is a
> higher one... especially in a world where one man's best practice is
> another man's nightmare (and since we are human we all need to
> remember that even if we are the first "man" in that sentence, the
> second "man" in the sentence may be us in the future).
>
> On the pragmatic note, we can deprecate and remove things, but I
> generally don't like it if there is no replacement. Once an adequate
> replacement is in place that people like in general, THEN we can
> consider deprecation and removal.
>
> Of course, if no one is using a certain feature, then we might as well
> toss it... hence my request for community feedback.
>
> -David
>

[Adam Heath-2]

Jacques Le Roux wrote:
> I'm not using it and I'd vote for commenting out. It's then oneself
> responsibility to use it or not
> I know Si is an active user and he will not answer since he unsubscribed
> from this list

Well, ok, then here's more info.  I am adding post-thread cleanup
functions.  What this will do, is in long running threads, create a
per-thread registry, and allow the thread loop to call cleanup
functions, depending on what code is called.

This requires having pretty tight control over how threads are created.
 This beanshell code doesn't allow for that, so at the very least, would
cause memory leaks.

[Jacques Le Roux]

That does not frighten me too much. Everybody has rights to shoot him/herself a bullet in the foot ;o)
Maybe your comment below add at all the block commented out will do the job ?

Jacques

From: "Adam Heath" <[hidden email]>

> Jacques Le Roux wrote:
>> I'm not using it and I'd vote for commenting out. It's then oneself
>> responsibility to use it or not
>> I know Si is an active user and he will not answer since he unsubscribed
>> from this list
>
> Well, ok, then here's more info.  I am adding post-thread cleanup
> functions.  What this will do, is in long running threads, create a
> per-thread registry, and allow the thread loop to call cleanup
> functions, depending on what code is called.
>
> This requires having pretty tight control over how threads are created.
> This beanshell code doesn't allow for that, so at the very least, would
> cause memory leaks.
>

[David E Jones-3]

On Dec 22, 2008, at 8:59 AM, Adam Heath wrote:

> Jacques Le Roux wrote:
>> I'm not using it and I'd vote for commenting out. It's then oneself
>> responsibility to use it or not
>> I know Si is an active user and he will not answer since he  
>> unsubscribed
>> from this list
>
> Well, ok, then here's more info.  I am adding post-thread cleanup
> functions.  What this will do, is in long running threads, create a
> per-thread registry, and allow the thread loop to call cleanup
> functions, depending on what code is called.
>
> This requires having pretty tight control over how threads are  
> created.
> This beanshell code doesn't allow for that, so at the very least,  
> would
> cause memory leaks.

For dev-time-only tools memory leaks aren't as big a concern. No one  
in their right mind would leave this enabled in production, and the  
production deployment docs even mention commenting it out.

-David