Groovysh container

[Jacques Le Roux]

Hi,

Thanks to Rene Scheibe, I have just commited (completed at revision: 1062476) a Groovysh container. It's just fine (though when you
type a char on Windows it's  duplicated, but it works, see https://issues.apache.org/jira/browse/OFBIZ-3954) but I wonder if we
should not rather provide those  Beanshell and Groovysh containers commented out. I know it will break the policy we use that
provide OOTB a develop friendly version  rather than an user/production ready. But it will prevent any admin/user oversights,
because it's an important security concern. If a dev needs them, it's really easy to uncomment? What do you think?

Thanks

Jacques

[BJ Freeman]

I would say keep the dev friendly pattern in the trunk.
I would change it in the relaase branches since they are more targeted
as end users.
write up a docbook section for the Tech on how to deal with them and the
security issues. use the id="" in the section so you can put a link on
the wiki to the section on the localhost.

add demo server script to comment them out if necessary.

on a side note, it would be great to add a note on the nightly builds
that these are meant for users without configuration.



=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Jacques Le Roux sent the following on 1/23/2011 10:04 AM:

> Hi,
>
> Thanks to Rene Scheibe, I have just commited (completed at revision:
> 1062476) a Groovysh container. It's just fine (though when you
> type a char on Windows it's duplicated, but it works, see
> https://issues.apache.org/jira/browse/OFBIZ-3954) but I wonder if we
> should not rather provide those Beanshell and Groovysh containers
> commented out. I know it will break the policy we use that
> provide OOTB a develop friendly version rather than an user/production
> ready. But it will prevent any admin/user oversights,
> because it's an important security concern. If a dev needs them, it's
> really easy to uncomment? What do you think?
>
> Thanks
>
> Jacques
>
>
>

[Bilgin Ibryam-2]

I agree with BJ here - keep it same as beanshell container.
If you want to comment them out (which I don't mind), we should discuss it
in another thread for default enabled containers/features in trunk...

my 2c

On Sun, Jan 23, 2011 at 6:25 PM, BJ Freeman <[hidden email]> wrote:

> I would say keep the dev friendly pattern in the trunk.
> I would change it in the relaase branches since they are more targeted as
> end users.
> write up a docbook section for the Tech on how to deal with them and the
> security issues. use the id="" in the section so you can put a link on the
> wiki to the section on the localhost.
>
> add demo server script to comment them out if necessary.
>
> on a side note, it would be great to add a note on the nightly builds that
> these are meant for users without configuration.
>
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation  <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
> Jacques Le Roux sent the following on 1/23/2011 10:04 AM:
>
>
>  Hi,
>>
>> Thanks to Rene Scheibe, I have just commited (completed at revision:
>> 1062476) a Groovysh container. It's just fine (though when you
>> type a char on Windows it's duplicated, but it works, see
>> https://issues.apache.org/jira/browse/OFBIZ-3954) but I wonder if we
>> should not rather provide those Beanshell and Groovysh containers
>> commented out. I know it will break the policy we use that
>> provide OOTB a develop friendly version rather than an user/production
>> ready. But it will prevent any admin/user oversights,
>> because it's an important security concern. If a dev needs them, it's
>> really easy to uncomment? What do you think?
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
>>