View Issue Details

IDProjectCategoryView StatusLast Update
0021191Open CASCADEOCCT:Data Exchangepublic2017-06-28 16:58
ReporterabvAssigned Togka 
PrioritynormalSeveritytrivial 
Status assignedResolutionopen 
OSAll 
Summary0021191: Inconvenient configuration of shape processing in DE translators
DescriptionCurrent implementation of shape processing in data exchange components is
inconvenient in general and non-safe for use in multithreaded applications, due
to usage of static resource manager configured via resource files and
environment variables.

In particular, the following known problems exist:

A. Implementation problems (see method ShapeProcess_Context::LoadResourceManager
()):

- Resource manager is implemented as static object; this leads to potential
conflict if translators are used in multithreaded environment

- Check for modification of resource file is implemented in completely wrong
way, as the string being checked is not actually a file name but name of
resource (e.g. "STEP")

- In debug mode, unnecessray messages are printed to cout

B. Conceptual problem is the fact that resources are loaded from file whose
location is defined by environemnt variable, which can be set effectively only
before application start (note that in DRAW command "set env(CSF_STEPDefaults)"
does not change actual runtime environment of OCCT components). This means that
application cannot change settings at runtime. And in general configuration via
resources file is inconvenient and may be unacceptable in real-world
applications (cf. MTWZ remark on MTWZ-07-001)

The proposed solution is to get rid of static resource manager and instead
provide API for manipulating shape processing context on the level of high-
level DE tools (Reader/Writer). The interface should allow to manipul;ate
parameters programmetically; loading from resource file can be kept as default
option for compatibility (and probably still useful under some circumstances).

The basic idea is that the code that calls DE component should control
completely the way how parameters are defined, without a need for "implicit"
definitions via environment variables, resource files etc.
TagsNo tags attached.
Test case numberNot required

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2011-01-20 12:35 bugmaster BugsThisDependsOn => 22190
2011-01-20 12:37 bugmaster BugsThisDependsOn 22190 =>
2011-08-02 11:12 bugmaster Category OCCT:DTE => OCCT:Data Exchange
2017-06-28 16:58 apv Test case number => Not required
2017-06-28 16:58 apv Fixed in Version EMPTY =>
2017-06-28 16:58 apv Description Updated
2017-06-28 16:58 apv Assigned To bugmaster => gka
2017-06-28 16:58 apv Status new => assigned