Re: Plugin and initialize() method
Jarl,
What's not to like about it? Maybe it isn't the most efficient way, but init
is just once per thread. For long running processes like the plugin server
that's just a minor overhead for the first user(s) of the plugin server.
Multiple plugin servers will just make your life harder I think. You'd have
to know which plugin server instance is running a particular plugin, update
the ar.conf to create aliasses to the plugins etc etc. In the end you don't
gain much.
Hugo
on 10/10/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I also see if you have several plugins, all loads the initialize()
method when the first plugin are accessed.
I really dont like this method doing it, seems like there is a need
for several plugin-servers.
--
Jarl
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hi,
Found this documentation, and this put a new ligth on my initial
question.
---
All plugins can implement a public void static init(ARPluginContext
context) method to do all intialization for this class. This will be
invoked once for each class that implements one of the ARPluggable
interfaces on plugin server startup. This same thing can be
accomplished using a static block of code in the class. The only
advantage in implementing this method is that it gets access to the
ARPluginContext object that can be used for the following purposes.
1. Logging any initialization messages
2. Fetching configuration file entries for this plugin from
pluginsvr_config.xml file.
3. Get AR System configuration entries from the ar.cfg file.
For all instance initialization, the public initialize(ARPluginContext
context) should be used. The initialize method is invoked once for
each thread instance in plugin server.
---
Still i like the C plugin better then, where you have an Termination
function.
--
Jarl
On 10/4/07, Hugo Visser [EMAIL PROTECTED] wrote:
** Right, the way I read the javadoc I understand that the initialize
will
be called once the plugin is loaded. From the javadoc I can not tell
for
sure if that moment is the plugin server is started. It's not clear
what is
meant with at startup load time...It could be the plugin server
start up,
but it could also mean when the plugin is first started.
But in the end it really doesn't matter how and when it is
initialized.
That's just an implementation detail. Just as you initialize at the
correct
moment :) The only catch is that the initialize seems to be called
once for
every thread that the plugin server starts (so I've been told). That
isn't
really documented either...
Hugo
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and
Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server
runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as
_it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter
calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents
the
AREA, ARDBC, or AR Filter calls from doing things like spawning
new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong
about.)
Then... when the Plugin server is being shut down I think the
Re: Plugin and initialize() method
Exaclty; not very efficient. And its behave different from the C plugins...
--
Jarl
On 10/10/07, Hugo Visser [EMAIL PROTECTED] wrote:
** Jarl,
What's not to like about it? Maybe it isn't the most efficient way, but init
is just once per thread. For long running processes like the plugin server
that's just a minor overhead for the first user(s) of the plugin server.
Multiple plugin servers will just make your life harder I think. You'd have
to know which plugin server instance is running a particular plugin, update
the ar.conf to create aliasses to the plugins etc etc. In the end you don't
gain much.
Hugo
on 10/10/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I also see if you have several plugins, all loads the initialize()
method when the first plugin are accessed.
I really dont like this method doing it, seems like there is a need
for several plugin-servers.
--
Jarl
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hi,
Found this documentation, and this put a new ligth on my initial
question.
---
All plugins can implement a public void static init(ARPluginContext
context) method to do all intialization for this class. This will be
invoked once for each class that implements one of the ARPluggable
interfaces on plugin server startup. This same thing can be
accomplished using a static block of code in the class. The only
advantage in implementing this method is that it gets access to the
ARPluginContext object that can be used for the following purposes.
1. Logging any initialization messages
2. Fetching configuration file entries for this plugin from
pluginsvr_config.xml file.
3. Get AR System configuration entries from the ar.cfg file.
For all instance initialization, the public initialize(ARPluginContext
context) should be used. The initialize method is invoked once for
each thread instance in plugin server.
---
Still i like the C plugin better then, where you have an Termination
function.
--
Jarl
On 10/4/07, Hugo Visser [EMAIL PROTECTED] wrote:
** Right, the way I read the javadoc I understand that the initialize
will
be called once the plugin is loaded. From the javadoc I can not tell
for
sure if that moment is the plugin server is started. It's not clear
what is
meant with at startup load time...It could be the plugin server
start up,
but it could also mean when the plugin is first started.
But in the end it really doesn't matter how and when it is
initialized.
That's just an implementation detail. Just as you initialize at the
correct
moment :) The only catch is that the initialize seems to be called
once for
every thread that the plugin server starts (so I've been told). That
isn't
really documented either...
Hugo
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and
Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server
runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as
_it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter
calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents
the
AREA, ARDBC, or AR Filter calls from doing things like spawning
new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception
Re: Plugin and initialize() method
I also see if you have several plugins, all loads the initialize()
method when the first plugin are accessed.
I really dont like this method doing it, seems like there is a need
for several plugin-servers.
--
Jarl
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hi,
Found this documentation, and this put a new ligth on my initial question.
---
All plugins can implement a public void static init(ARPluginContext
context) method to do all intialization for this class. This will be
invoked once for each class that implements one of the ARPluggable
interfaces on plugin server startup. This same thing can be
accomplished using a static block of code in the class. The only
advantage in implementing this method is that it gets access to the
ARPluginContext object that can be used for the following purposes.
1. Logging any initialization messages
2. Fetching configuration file entries for this plugin from
pluginsvr_config.xml file.
3. Get AR System configuration entries from the ar.cfg file.
For all instance initialization, the public initialize(ARPluginContext
context) should be used. The initialize method is invoked once for
each thread instance in plugin server.
---
Still i like the C plugin better then, where you have an Termination function.
--
Jarl
On 10/4/07, Hugo Visser [EMAIL PROTECTED] wrote:
** Right, the way I read the javadoc I understand that the initialize will
be called once the plugin is loaded. From the javadoc I can not tell for
sure if that moment is the plugin server is started. It's not clear what is
meant with at startup load time...It could be the plugin server start up,
but it could also mean when the plugin is first started.
But in the end it really doesn't matter how and when it is initialized.
That's just an implementation detail. Just as you initialize at the correct
moment :) The only catch is that the initialize seems to be called once for
every thread that the plugin server starts (so I've been told). That isn't
really documented either...
Hugo
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
Re: Plugin and initialize() method
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:* arslist@ARSLIST.ORG
*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: arslist@ARSLIST.ORG
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.USERLISTinitialize()
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
Re: Plugin and initialize() method
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
On 10/4/07, Hugo Visser [EMAIL PROTECTED] wrote:
** 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:JarlGrøneng
Newsgroups:public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Sent: Wednesday, October 03, 2007 12:59PM
Subject: Re: Plugin and initialize()method
**
I dont see how the servlets fits in here? I wrote a javabased plugin,
and loaded it trough the java pluginserver.
--
Jarl
On 10/3/07, Dan Reitan [EMAIL PROTECTED] wrote:
Jarl,
I can confirm Axton's observations with C++ plugins,but only circa
v6.x.
Would you conclude from your logs that7.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 releaseto see if they are fully
compliant with the 7.1 pure Java clientAPI?
Curious, and hoping to get my fingers dirty with thisnew stuff within
a few
weeks...
Thanks,
Dan
- Original Message -
From: Jarl Grøneng [EMAIL PROTECTED]
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Sent:Wednesday, October 03, 2007 9:47 AM
Subject: Re: Plugin andinitialize() 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 logsare available at:
http://arswiki.org/projects/arfprng/wiki/UserDocs
Looks like ARPluginInitialization is only calledwhen 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 pluginserverstart.
An initialization routine called once at startupload time for
each
plugin that is loaded. The plugincan do all its initialization
and
setup in this method.
This is what plugin.log shows onstartup:
2007-10-03 17:37:00,750INFO [main]
com.bmc.arsys.pluginsvr.plugins.g
(?:?) - The plugin url is
file:/C:/Documents%20and%20Settings/jag/My
Re: Plugin and initialize() method
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Plugin and initialize() method
For the C plug-ins, ARPluginCreateInstance and ARPluginDeleteInstance
are called each time a plug-in is called.
These 3 are called when the plug-in server starts:
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginDeleteInstance is called before the plug-in call (from an end
user) exits.
ARPluginTermination is called for each plug-in when the plug-in server
terminates.
The idea here is:
- ARPluginInitialization and ARPluginTermination allow you to set up
global resources.
- ARPluginCreateInstance and ARPluginDeleteInstance allow you to set
up resources specific to a single call to the plugin.
- ARPluginIdentify sets up the data that is mandatory to the
functioning of the plug-in (i.e., who am I, what version am I, ...).
- ARPluginSetProperties exposes pointers to various functions that are
provided by the plug-in server.
Axton Grams
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Plugin and initialize() method
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Plugin and initialize() method
Very useful info, Jarl -- thanks.
Hugo,
Thanks for the answer re: 7.1 Mid-Tier JNI dependency.
It was very helpful -- though not the answer I wanted to hear, though it has
been confirmed elsewhere.
Based on logs in recent thread Re: Mid-Tier 7.1 on Linux Apache Tomcat
5.5.23 (UNCLASSIFIED)
it appears that authentication is still using JNI.
As to the event-container issue, it is not an issue, just a discussion at
a different layer of abstraction, which does not seem to be serving anybody
but me, so I will drop it.
(though I think your discussion and Jarl's recent finding tends to reinforce
the idea -- depends still on whether persistence is managed differently than
C plugin)
It was an attempt to understand why instead of just what, and whether it
was a bad port or just bad documentation, and if there are likely to be
other surprises.
Dan
- Original Message -
From: Jarl Grøneng [EMAIL PROTECTED]
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Sent: Thursday, October 04, 2007 7:56 AM
Subject: Re: Plugin and initialize() method
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers
Are
Re: Plugin and initialize() method
Right, the way I read the javadoc I understand that the initialize will be
called once the plugin is loaded. From the javadoc I can not tell for sure
if that moment is the plugin server is started. It's not clear what is meant
with at startup load time...It could be the plugin server start up, but it
could also mean when the plugin is first started.
But in the end it really doesn't matter how and when it is initialized.
That's just an implementation detail. Just as you initialize at the correct
moment :) The only catch is that the initialize seems to be called once for
every thread that the plugin server starts (so I've been told). That isn't
really documented either...
Hugo
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits running initialize when the plugin loads.
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Plugin and initialize() method
Hi,
Found this documentation, and this put a new ligth on my initial question.
---
All plugins can implement a public void static init(ARPluginContext
context) method to do all intialization for this class. This will be
invoked once for each class that implements one of the ARPluggable
interfaces on plugin server startup. This same thing can be
accomplished using a static block of code in the class. The only
advantage in implementing this method is that it gets access to the
ARPluginContext object that can be used for the following purposes.
1. Logging any initialization messages
2. Fetching configuration file entries for this plugin from
pluginsvr_config.xml file.
3. Get AR System configuration entries from the ar.cfg file.
For all instance initialization, the public initialize(ARPluginContext
context) should be used. The initialize method is invoked once for
each thread instance in plugin server.
---
Still i like the C plugin better then, where you have an Termination function.
--
Jarl
On 10/4/07, Hugo Visser [EMAIL PROTECTED] wrote:
** Right, the way I read the javadoc I understand that the initialize will
be called once the plugin is loaded. From the javadoc I can not tell for
sure if that moment is the plugin server is started. It's not clear what is
meant with at startup load time...It could be the plugin server start up,
but it could also mean when the plugin is first started.
But in the end it really doesn't matter how and when it is initialized.
That's just an implementation detail. Just as you initialize at the correct
moment :) The only catch is that the initialize seems to be called once for
every thread that the plugin server starts (so I've been told). That isn't
really documented either...
Hugo
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
I have no proble understand how the plugin-server handle these
funstion. But it seems that there is a difference in how a C and Java
plugin behave.
TAnd the plugin documentation states this:
initialize(ARPluginContext context)
An initialization routine called once at startup load time for each
plugin that is loaded.
And this does not happend when the plugin loads, it happend when it
gets accessed first time. And for each thread the plugin-server runs.
The documentation should be like this:
An initialization routine called once at startup load time for each
thread instance.
If you add this to the plugin:
public static void init(ARPluginContext context){
//
};
It does this function when its loads. Sems like I have to move my
initialization code here.
--
Jarl
On 10/4/07, Carey Matthew Black [EMAIL PROTECTED] wrote:
Jarl,
I think there might be a bit of confusion due to the terms used...
I think it is more like this...
Ref: Integrating-710.pdf pg 102
Figure 7-2: C plug-in call sequence
ARPluginIdentify ()
ARPluginSetProperties ()
ARPluginInitialization ()
ARPluginCreateInstance() -- one or more times
AREA, ARDBC, or AR Filter calls --
I think this is per Filter Action
ARPluginDeleteInstance ()
ARPluginTermination ()
I think... the plugin server calls the first 4 methods as soon as _it_
starts up. Then when the ARS Server talks to the Plugin Server the
only things that are done are the AREA, ARDBC, or AR Filter calls
portion(s) of the code.
I think this makes some sense too. But I do not think it prevents the
AREA, ARDBC, or AR Filter calls from doing things like spawning new
threads (ARPluginCreateInstance() ) or other calls to the previous
methods. ( With a possible exception of the ARPluginIdentify ()
method. I doubt the Plugin Server would deal with a loaded plugin
trying to change its identity very well. But I could be wrong about.)
Then... when the Plugin server is being shut down I think the
ARPluginDeleteInstance () and ARPluginTermination () methods are
called.
So in summary when the plugin loads is when the Plugin Server reads
and loads the plugin into memory on startup. (And not when a Plugin
Call from the ARS server is executed.) The plugins are standing
daemons that wait and listen for inquiries.
But that is just my read of things. (Reality might be very different
than what the docs indicate.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.
On 10/4/07, Jarl Grøneng [EMAIL PROTECTED] wrote:
Hugo,
The documentation of the java plugin states this:
public void initialize(ARPluginContext context) throws ARException {}
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.
I see benefits
Plugin and initialize() method
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.USERLISTinitialize()
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.USERLISTgetListEntryWithFields()
..
..
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
Re: Plugin and initialize() method
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.USERLISTinitialize()
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.USERLISTgetListEntryWithFields()
..
..
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.org ARSlist:Where the
Answers Are
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.USERLISTinitialize()
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.USERLISTgetListEntryWithFields()
..
..
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.org ARSlist:Where the
Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Plugin and initialize() method
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: arslist@ARSLIST.ORG
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.USERLISTinitialize()
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.USERLISTgetListEntryWithFields()
..
..
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.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers
Are
Re: Plugin and initialize() method
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
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
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] 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: arslist@ARSLIST.ORG
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.USERLISTinitialize()
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.USERLISTgetListEntryWithFields()
..
..
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.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers
