The build process should have been modified in the patch to not build the webmethods-specific components without the presence of the appropriate jars - unfortunately I hadn't quite thought things through and considered that the components need to build in the absence of the libraries.
It would be feasible to rewrite the webMethods-specific code to use reflection, therefore allowing it to build without the jars, and there would simply be a requirement to drop the commercial libraries in at runtime to get things to work. Since this would be a somewhat time-consuming alteration to make, I would first like to get opinion on if I should bother! If the overall project does not have sufficient interest in including EAI tools as protocols, then I can maintain a codebase for my own personal use. As to having support for only one vendor: to my knowledge, there are no widely used non-proprietary EAI products. My intention with this release for webMethods specifically was to add the first of several protocols, that over time will be able to address a range of EAI tools rather than focusing on one - my work requirements meaning that the first one completed was the webMethods one. In summary: I can alter the code to allow dynamic loading of the neccessary (commercial) jar files, but I would like some opinion on whether or not there is the demand. Cheers, Conor. On 10/25/05, sebb <[EMAIL PROTECTED]> wrote: > We would need to ensure that JMeter still _ran_ if the jars were > absent. That's probably just a case of including appropriate try/catch > bolcks. > > Easy enough to fix the build process so that the methods are not built > if the jars are absent, but someone needs to build it... > > Depending on how easy it is for developers to get hold of the jars, > and what the licence restrictions are, it may be necessary to ensure > that the code can be built without the jars. > > Now, one can use commercial (or opensource) JDBC jars without needing > them to build against, but whether this is easy or possible to do in > this case is another matter. > > The other issue is whether there are any other opensource > implementations of the webMethods API. I'm not sure we want to add > support for a single commercial vendor. > > S. > On 25/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· > > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > > <http://issues.apache.org/bugzilla/show_bug.cgi?id=36721>. > > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· > > INSERTED IN THE BUG DATABASE. > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=36721 > > > > > > > > > > > > ------- Additional Comments From [EMAIL PROTECTED] 2005-10-25 03:58 ------- > > I looked at the docs in the attachment. thanks for including docs. in the > > doc, > > it states: > > > > General notes on the webMethods samplers. The implementation uses the > > webMethods Java Client API and Broker Client API, which requires the > > client.jar, wmbrokerclient.jar (Broker v6.5), client61.jar (Broker v6.1) or > > client601.jar (Broker v6.01) from webMethods. Due to license restrictions, > > JMeter does not include the jar files in the binary distribution. Please > > refer > > to > > <a href="http://advantage.webmethods.com";>webMethods Advantage Partner > > Site</a> > > for details. > > > > I'll have to consult the other committers about the licensing issues. We > > may be > > able to accept the contribution, if we don't have the jar files in > > subversion > > and only download the required jars to build jmeter. I don't know how that > > would work, but perhaps sebb can respond with the feasibility of that. > > > > peter > > > > -- > > Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
