Can Proparse be a static ?
Wed, 2008-08-13 19:14 — jmls
Is there any need for having more than one ProParse class in memory at once (there may be a need for several ParseUnits). If not, should we not make ProParse.cls a static class ?
- Login to post comments
Re: Can Proparse be a static ?
Is it reasonably possible that a single OpenEdge session might want to reference more than one instance of Proparse?
Tell me if that's a valid way of re-asking your question... maybe I'm answering the wrong question!
The answer is "yes". It would reasonable to have two instances of the proparse.jar server running. Each instance would be parsing a different source code directory structure, with a different DB schema, with a different propath. As examples, development vs. testing, or a few different variants of the application each customized for different vertical markets.
A single Prolint session might never work this way (only Jurjen knows) but I can easily envision a developer using Proparse for impact analysis across several workspaces (projects) at once.
PS: Just "Proparse" please, not "ProParse". :-)
John: The answer is "yes".
John: The answer is "yes". It would reasonable to have two instances of the proparse.jar server running. Each instance would be parsing a different source code directory structure, with a different DB schema, with a different propath.
A Progress process can only have one Propath, one session handle, one DB schema (even if more db's are connected they are together one schema). When you want to work on two workspaces at the same time you need two Progress processes.
When each workspace needs its own proparse.jar server, and apparently its own Progress process too, then I feel it is overcomplicated to design that a single Progress process can handle multiple Proparse.jar servers.
If it is overcomplicated, then it goes wrong. I'd say make it so that Proparse.cls is a Singleton.
Aaah, I took the question as
Aaah, I took the question as "does it make sense to have more than one instance of Proparse.cls in a Progress session".
And I think the answer is: the session can't parse with zero instances of proparse.cls (so it can't be a static class), it works very well with one instance, it works less than good with multiple simultanious instances (so it better be a singleton).
It never occured to me that there may have to be more than 1 proparse.jar running as a server. That means there has to be some negociating to get a free port? Does it also mean that the lifetime of a proparse.jar is equal to the lifetime of a Progress session, or a Proparse.cls object instance?
About Prolint: a developer typically has a dev workspace, a test workspace and a bunch of maintenance workspaces. Typically, each workspace is a Progress session with its own propath, settings, databases etc. He may have started more than one workspace sessions at the same time. Prolint and the current Proparse are just tools that works in the context if such a Progress session.
If the Progress session would switch to a different workspace (ie disconnect db's, connect to a different set of db's, change the propath, change some more session params) then Prolint won't get confused, because Proparse.dll will also refresh its settings and Prolint keeps nothing in memory anyway.
Re: Aaah, I took the question as...
That means there has to be some negociating to get a free port?
For the typical Prolint user, there would be one proparse.jar server, running on the same workstation as Prolint, and in fact, it would probably be launched and controled by that Prolint session.
In more general terms though, proparse.jar can be launched as a server on any machine, and the TCP port# that it listens on is configurable. Maybe a company would have 4 proparse.jar servers running on 4 computers! One for devel, one for test, one for their Lumber customizations, and one for their Tire customizations (as examples).
I know that at Jurjen's company, Prolint is run at the developer's workstation just prior to code check-in. But remember that some businesses just wanted Prolint running on a server and generating reports!
It's not uncommon for businesses to have shared, central 'builds' of every configuration of the application, and these get used in a read-only fashion for all sorts of system analysis and reporting. Think of a proparse.jar server running for each of those configurations. Clients could query any or all of those servers when doing system wide analysis.
Good enough. More than one
Good enough. More than one it is then. Of Proparse, of course. :)
That does not make sense to
That does not make sense to me. More than one instance of Proparse.cls in each Progress session???? More than one ParseUnit in a Proparse context is already a novelty, but two++ Proparse.cls instances is confusing, and probably a bad idea since its initialization is quite heavy (making a socket connection, launch proparse.jar if not already listening, build the memory pool for ParseUnits...) and I do not see a use case for it.
John mentions multiple workspaces, but a Progress session can not run multiple workspaces at the same time. It can only switch between workspaces.
Progress session vs. server session
OK, you don't see it being useful for Prolint, and that's fair enough. Prolint is a little special because it fits in so tightly with the developer's Progress session (compiler, DB connections, propath).
Outside of Prolint though, I do see valid reasons to be referencing multiple proparse.jar servers. I don't think it would hurt Prolint if Proparse.cls was just a regular object instance, rather than static or singleton.
Consider a business that sets up one or more shared proparse.jar servers.
The client could have a single Proparse.cls that is switched back and forth between the different servers (i.e. tell Proparse.cls to use a different TCP port), or as a much better alternative, each Proparse.cls would reference a single proparse.jar server on a specified port.
I don't think that it is as
I don't think that it is as complicated as people are making it out to be :)
Proparse.cls communicates with proparse.jar through a socket when and only when it needs to send or receive some information. The server and port can be changed at will by setting the appropriate properties.
The _only_ reason I wanted it to be a static was to save some coding lines - not having to NEW or find the object in memory etc.
Sorry, no it is not just
Sorry, no it is not just that I don't see it being useful for Prolint.
Sure I understand why a company would have several shared proparse servers, in order to work on several different workspaces.
I also understand that it must be possible to parse/lint/refactor different workspaces simultaniously. What I do not get, is why this has to be done by a single Progress executable. It is so much easier to spawn more than one Progress executable, have them each work on a workspace. It is not only easier but also probably faster, because a single process can't multi-task and can't be executed on more than one machine at a time.
The only reason I can imagine why one would parse multiple workspaces simultaniously in a single session, is when there are dependencies between those workspaces and the parsing processes have synchronisation points (parse workspace A to point X and then workspace B to point X, compare results, then parse some more in workspace A and B). Is that a scenario you are thinking about? Apart from that, I do not understand what requires that a single Progress process must be able to support multiple instances of Proparse.cls.
And yes, from a Prolint perspective it is inconvenient too. Prolint is not used as a batch that reports once for the entire workspace. Instead, it is invoked repeatedly during a Progress session. On each invocation prolint.p must get a handle to a Proparse.cls instance. If multiple instances happen to be running, then which instance is the right one? Is there at least a singleton object somewhere that manages the Proparse instances and that can be queried to get the right instance? Or should Prolint just ignore running instances and, to be on the safe side, initialize and destroy its own Proparse.cls instance? Nah that takes too much time.
Maybe we have to split. Maybe it is better if 'proparseclient' is the multi-instance api with temp-tables and node classes, and a different project has a single-instance api optimized for Prolint. If so, might as well try that with persistent procedures instead of OO to make sure it works in dlc9.
I don't see why it has to be
I don't see why it has to be enforced within Proparse.cls that it is a singleton (or static). It's trivial for Prolint to have its own static method for creating, managing, and fetching its own reference to an instance of Proparse.cls.
Let's see if we can put this discussion to bed. Singleton or not is unlikely to have much impact on me, so I'll shut up about it. You and Julian both want a static/singleton class, so go ahead with that. If I ever want multiple instances, I can always just create a new class for it.
Now if you went with DLC9, how would you enforce that there's only ever one single handle to the persistent proparse.p? ;-)
re: can Proparse be a static
My understanding of OO is that it can't be a static class because it has state, so there must be an instance to keep the state in.
It can (and certainly should) be a Singleton though, to guarantee that you can't have more than one instance.
yeeeeesssssss, but, as we
yeeeeesssssss, but, as we don't have singletons without yucky code to search through memory for the class in question, can't we just declare it as a static so that we can use it as a singleton ?
Please ?
Pretty please ?
;)
Well no, not possible,
Well no, not possible, because you need an instance. Unless the class has no datamembers, but I can't see how proparse.cls does not have datamembers: it manages a list of ParseUnit instances, it has pointers to delegated classes, it has a socket to proparse.jar....
How yucky would the implementation of the static proparse:instance method be, really? When there are tens of thousands Node instances in memory then it may not be fast to walk the session:first-object:next-sibling chain. But it is a small and clear piece of code, relatively not so yucky I'd say.
Or maybe I am just wrong about what a static class is?