Dan, I don't really see the issue here. There is a difference in implementation for the Java plugin server and the C plugin server. For example, the C plugin server will only start one thread unless you configure the plugin server otherwise. The C plugin server will initialize the plugin when the plugin server loads. However, it seems that the Java implementation creates more threads initially and will initialize the plugin at a later stage (on first use).
It's important to realize that the plugin server (either the C or Java version) can create a new instance for the plugin class. That would also cause the initialize to be called again. That could explain the "spurious" initializes. They are not actually suprious, but they are initializations of new plugin instances. On the pure Java Mid-Tier question: the Mid-Tier uses the Java API which is currently a mix of pure Java and JNI. When connecting to older servers the JNI stuff will be used, and the JNI code will also be used for functions that are not (yet) implemented in the pure Java code. It's not documented which functions use native code and which functions do not when connecting to a 7.1. server so for now I would try to play it safe and assume that the Mid-Tier still requires the JNI layer. Hope this helps, Hugo On 10/3/07, Dan Reitan <[EMAIL PROTECTED]> wrote: > > ** I'm not saying servlets were involved -- it just appears that the > initialization logic follows the servlet lifecycle specification. > > I'm "thinking out loud" here to understand why the behavior may be > different between C++ and Java Plugin, but am speculating that the Java > Plugin JNI (which, I believe is simply a bridge between C++ plug-in and Java > plugin environment) may treat the C++ plugin environment as an event > container (similar to Servlets treating HTTP server requests), and manage > JVM env. / garbage collection/ etc. similarly, which would result in > spurious, "random", asynchronous intialization events. > > ... just a theory... > > ...also curious about the mid-tier pure-java question, since it has such a > dramatic impact on architecture. > > Dan > > > ----- Original Message ----- > *From:* Jarl Grøneng <[EMAIL PROTECTED]> > *Newsgroups:* public.remedy.arsystem.general > *To:* [email protected] > *Sent:* Wednesday, October 03, 2007 12:59 PM > *Subject:* Re: Plugin and initialize() method > > ** > I dont see how the servlets fits in here? I wrote a java based plugin, and > loaded it trough the java plugin server. > > -- > Jarl > > On 10/3/07, Dan Reitan <[EMAIL PROTECTED] <[EMAIL PROTECTED]>> wrote: > > Jarl, > > > > I can confirm Axton's observations with C++ plugins, but only circa v6.x > . > > > > Would you conclude from your logs that 7.1 Java Plugin is patterned > after > > the Servlet lifecycle model? > > Is there any overlap of the Plugin JNI libs with the previous > > ARS-Java-client JNIs? > > Have you looked at the current MidTier release to see if they are fully > > compliant with the 7.1 "pure Java" client API? > > > > Curious, and hoping to get my fingers dirty with this new stuff within a > few > > weeks... > > > > Thanks, > > > > Dan > > > > > > ----- Original Message ----- > > From: "Jarl Grøneng" < [EMAIL PROTECTED]> > > Newsgroups: public.remedy.arsystem.general > > To: <[email protected]> > > Sent: Wednesday, October 03, 2007 9:47 AM > > Subject: Re: Plugin and initialize() method > > > > > > > Thanks, > > > > > > Then it seems like there is a difference in how the java plugin-server > > > loads the java-plugin. > > > > > > -- > > > Jarl > > > > > > On 10/3/07, Axton <[EMAIL PROTECTED]> wrote: > > >> I have a C based arfilter plug-in. The logs are available at: > > >> > > >> http://arswiki.org/projects/arfprng/wiki/UserDocs > > >> > > >> Looks like ARPluginInitialization is only called when the plug-in > > >> server is started. > > >> > > >> Axton > > >> > > >> On 10/3/07, Jarl Grøneng <[EMAIL PROTECTED]> wrote: > > >> > From the documentaion, the function: > > >> > public void initialize(ARPluginContext context) throws ARException > {} > > >> > should be loaded when the pluginserver start. > > >> > "An initialization routine called once at startup load time for > each > > >> > plugin that is loaded. The plugin can do all its initialization and > > >> > setup in this method. " > > >> > > > >> > This is what plugin.log shows on startup: > > >> > > > >> > 2007-10-03 17:37:00,750 INFO [main] > com.bmc.arsys.pluginsvr.plugins.g > > >> > (?:?) - The plugin url is > > >> > > file:/C:/Documents%20and%20Settings/jag/My%20Documents/Java/ListCurrentUsers/ListCurrentUsers/deploy/listcurrentusers.jar > > > >> > 2007-10-03 17:37:00,750 INFO [main] > > >> > com.bmc.arsys.pluginsvr.ARPluginServerMain (?:?) - AR System Plugin > > >> > Server Version 7.1.00 Build 200708221849 > > >> > > > >> > > > >> > When I do a query on the vendor form, the initialize() function got > > >> > triggered: > > >> > > > >> > 2007-10-03 17:51:18,140 INFO [TCP server transport connection > thread] > > >> > com.bmc.arsys.pluginsvr.plugins.ARPluginContext (?:?) - > > >> > <SAMPLE.USERLIST>initialize() > > >> > 2007-10-03 17:51:18,468 INFO [TCP server transport connection > thread] > > >> > com.bmc.arsys.utils.CatalogReader (?:?) - constructor(arcatalog) > > >> > 2007-10-03 17:51:19,406 INFO [TCP server transport connection > thread] > > >> > com.bmc.arsys.api.ProxyManager (?:?) - Connects to ARServer pcjag2 > > >> > through [EMAIL PROTECTED] > > >> > 2007-10-03 17:51:19,421 INFO [TCP server transport connection > thread] > > >> > com.bmc.arsys.api.Proxy (?:?) - Api source is identified as: > > >> > AP016561457016WSrgRgQbYDAAKQAA > > >> > 2007-10-03 17:51:21,265 INFO [TCP server transport connection > thread] > > >> > com.bmc.arsys.pluginsvr.plugins.ARPluginContext (?:?) - > > >> > <SAMPLE.USERLIST>getListEntryWithFields() > > >> > .. > > >> > .. > > >> > > > >> > Anyone done a C based plugin that can confirm that this also > happend > > >> > with a C plugin? > > >> > > > >> > Regards, > > >> > Jarl > > >> > > > >> > > _______________________________________________________________________________ > > > >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > >> > ARSlist:"Where the Answers Are" > > >> > > > >> > > >> > _______________________________________________________________________________ > > >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where > > >> the Answers Are" > > >> > > > > > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where > > > the Answers Are" > > > > > > > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > > > __20060125_______________________This posting was submitted with HTML in > it___ > > __20060125_______________________This posting was submitted with HTML in > it___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
