jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: Separate folder for 3rd-party plugins
Date Mon, 04 Apr 2016 16:44:40 GMT
That makes sense.

The question of "when add it" is separate from "if add it". If your
objection is only for "when" then we have a time to discuss the idea.

Actually, I see an opportunity for this mechanism to actually slurp in
some of JMeter core plugin sets, like "mongodb", "mail" or "ftp" or
others. The way of "put JMeter functionality into same bucket with its
dependencies" might allow to isolate JARs that are rarely used and allow
to not load them in certain cases. This would crystallize core libraries
from functionality libraries, opening door to manage it.

I understand that JMeter's core is "time-proven", but time changes and
world evolves around us. At the time the core loading pieces were
created, there were not as many plugins and vendors. And now there are
tens of them. Makes sense to evolve the tool to reflect new realities.

sebb, can you review the code and say your opinion if it is truly
non-intrusive?

Others, can you express your opinion on this feature/idea? Milamber, Felix?

Andrey Pokhilko

On 04/04/2016 07:30 PM, sebb wrote:
> I am -1 for adding this in 3.0
>
> I don't think there's enough time to consider whether it truly is
> non-intrusive or even whether it is the best solution.
>
> It took quite a while to sort out JMeter class paths to ensure that
> classes are only loaded when necessary.
> The more jars there are in core JMeter, the more this becomes
> important to minimise memory consumption.
>
> It may turn out to be OK, but this is not something that can be added
> at the last minute.
>
>
> On 4 April 2016 at 17:19, Andrey Pokhilko <apc4@ya.ru> wrote:
>> How does it help to remove complexity from user? Is there a way to
>> seamlessly put bunch of files taken from plugin vendor and get them
>> loaded by JMeter? It's not convenient way to require users to edit
>> properties files every time they install plugins.
>>
>> Until now there was kinda "seamless" way of dropping JAR files into
>> "lib" and "lib/ext", but it mixes core JARs with third-party JARs,
>> making it difficult to solve possible conflicts.
>>
>> Why you object against some "new" mechanism in JMeter? Does it do any harm?
>>
>> Andrey Pokhilko
>>
>> On 04/04/2016 07:10 PM, sebb wrote:
>>> On 4 April 2016 at 14:34, Andrey Pokhilko <apc4@ya.ru> wrote:
>>>> Due to non-intrusive nature of the change, may I commit the change to
>>>> become part of 3.0 before we got first RC?
>>>>
>>>> Any objections?
>>> Yes, I object.
>>>
>>> Unless I am misunderstanding something there is *already* a mechanism
>>> for handling external jars and classes which is much more flexible.
>>>
>>> That is, the user.classpath property and the plugin_dependency_paths property.
>>>
>>>> Andrey Pokhilko
>>>>
>>>> On 04/04/2016 03:36 PM, Philippe Mouawad wrote:
>>>>> On Monday, April 4, 2016, Andrey Pokhilko <apc4@ya.ru
>>>>> <javascript:_e(%7B%7D,'cvml','apc4@ya.ru');>> wrote:
>>>>>
>>>>>> I've prepared a pull request, everyone can try playing with it:
>>>>>> https://github.com/apache/jmeter/pull/181/files
>>>>>>
>>>>>> The way it is done do not break any of existing jmeter class search
>>>>>> functionalities. In fact, it just extends the list of search paths
>>>>>> (thanks for hint, Philippe). So just more places searched for classes,
>>>>>> nothing more.
>>>>>>
>>>>>> Please review the pull request and tell me what you think. Including
if
>>>>>> it is safe to put it into 3.0 or not (it's my humble request, waiting
>>>>>> another year for next JMeter release is a bit too much :)
>>>>> It is a 3.0 so it took a bit more time.
>>>>> I think in future we should release more often (2/3 times a year unless
>>>>> there's no need).
>>>>>
>>>>> Note Andrei I didn't see you react on my 2/3 threads about releasing
:)  ,
>>>>> there is a last one open
>>>>>
>>>>>> Andrey Pokhilko
>>>>>>
>>>>>> On 04/04/2016 02:50 PM, Philippe Mouawad wrote:
>>>>>>> Yes it was a typo.
>>>>>>> This needs checking particularly for plugins that dynamically
search for
>>>>>> a
>>>>>>> class implementing an interface.
>>>>>>> I don't have access to my computer but it's for example  the
class/method
>>>>>>> that is used in ViewResultsTree to search for renderers. There
are other
>>>>>>> place where such mechanism is used.
>>>>>>> We need to be sure that placing plugin and dependencies in the
same
>>>>>> folder
>>>>>>> will not break this part.
>>>>>>>
>>>>>>> Regards
>>>>>>> Philippe
>>>>>>>
>>>>>>> On Monday, April 4, 2016, Andrey Pokhilko <apc4@ya.ru>
wrote:
>>>>>>>
>>>>>>>> I assume "we do plugin dependencies go" is misprint for "where".
>>>>>>>>
>>>>>>>> The idea is to make plugins dirs self-sufficient and, most
important,
>>>>>>>> don't touch jmeter's core "lib" and "lib/ext" dirs with plugins.
>>>>>>>>
>>>>>>>> No recursive search implied, just flat list of jars in directory
>>>>>> expected.
>>>>>>>> For example, both file of ssh-sampler plugin would be in
its dir:
>>>>>>>>
>>>>>>>> jmeter
>>>>>>>>   \ lib
>>>>>>>>    \ 3rdparty
>>>>>>>>     \ ssh-sampler
>>>>>>>>      \ ssh-sampler-1.0.jar
>>>>>>>>      | jsh-1.2.3.jar
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrey Pokhilko
>>>>>>>>
>>>>>>>> On 04/04/2016 02:37 PM, Philippe Mouawad wrote:
>>>>>>>>> Hi Andrei,
>>>>>>>>> With this approach, we do plugin dependencies go ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On Monday, April 4, 2016, Andrey Pokhilko <apc4@ya.ru
<javascript:;>>
>>>>>>>> wrote:
>>>>>>>>>> I'm fine with not putting this into 3.0, if it's
important for you to
>>>>>>>>>> release it ASAP and you see a risk with this addition.
I myself don't
>>>>>>>>>> see any risks as long as change is made and reviewed
carefully.
>>>>>>>>>>
>>>>>>>>>> With "search_paths" property, the problem is that
user has to
>>>>>>>>>> reconfigure it for every new plugin set he installs.
So instead of
>>>>>>>>>> simplifying life for user we would complicate it.
"search_paths"
>>>>>>>>>> property implies that there's single and predictable
plugins set for
>>>>>>>>>> installation. My idea is to have directory structure
agreement that
>>>>>>>>>> allows any number of separate plugin sets from any
vendors.
>>>>>>>>>>
>>>>>>>>>> Andrey Pokhilko
>>>>>>>>>>
>>>>>>>>>> On 04/04/2016 02:24 PM, Philippe Mouawad wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 3.0 is very close to release, I suggest we freeze
new dev now and
>>>>>>>> release
>>>>>>>>>>> it.
>>>>>>>>>>> I have been asked tens of time when it's out.
>>>>>>>>>>> This can be done in 3.1
>>>>>>>>>>>
>>>>>>>>>>> For info, this can already be done currently
with search_paths
>>>>>> property
>>>>>>>>>> and
>>>>>>>>>>> user.classpath one.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> On Monday, April 4, 2016, Refael Botbol <refael@blazemeter.com
>>>>>>>> <javascript:;>
>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>>> I'm using lots of 3rd party plugins with
JMeter and to me it will
>>>>>> make
>>>>>>>>>> life
>>>>>>>>>>>> much easier because:
>>>>>>>>>>>>
>>>>>>>>>>>>    1. If i'm installing a new plugin which
crashes - i can uninstall
>>>>>>>> it
>>>>>>>>>>>>    quickly.
>>>>>>>>>>>>    2. It will give a clear list of which
plugins I'm currently using
>>>>>>>>>> incase
>>>>>>>>>>>>    I need to run my script on a different
machine
>>>>>>>>>>>>    3. Upgrading JMeter to a newer version
will be almost seamless
>>>>>>>> (just
>>>>>>>>>>>>    updating the path to my 3rd party plugin..)
that way I don't need
>>>>>>>> to
>>>>>>>>>>>>    duplicate every plugin across multiple
JMeter versions I have
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 4, 2016 at 1:47 PM Andrey Pokhilko
<apc4@ya.ru
>>>>>>>> <javascript:;>
>>>>>>>>>> <javascript:;> <javascript:;>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> No, I don't mean OSGification. I mean
just classpath building.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In case of library clash the earlier
entry in classpath will win.
>>>>>> At
>>>>>>>>>>>>> least, there will be easy way to understand
which plugins set
>>>>>> brings
>>>>>>>>>>>>> which library and reveal the plugins
conflicts. For now, all guavas
>>>>>>>> go
>>>>>>>>>>>>> into "lib" and you look at it with no
idea "why did it happen and
>>>>>> how
>>>>>>>>>> to
>>>>>>>>>>>>> go out of it".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrey Pokhilko
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 04/04/2016 01:34 PM, Vladimir Sitnikov
wrote:
>>>>>>>>>>>>>> Do you mean some kind of OSGification?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What if different 3rdparties try
to include different versions of,
>>>>>>>>>> say,
>>>>>>>>>>>>> guava?
>>>>>>>>>>>>>> Which version will ultimately be
loaded in your suggested
>>>>>> approach?
>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>> --
>>>>>>>>>>>> Refael Botbol, BlazeMeter.
>>>>>>>>>>>> Director of Professional Services
>>>>>>>>>>>>


Mime
View raw message