I'm building from the latest CVS bits (JDK 1.5, JWSDP 1.6, Tomcat
5.0.28) and get the following errors during build compile:
bxml\omar\common\I18n-rim.xsl (The system cannot find the path
[java] at java.io.FileInputStream.open(Native Method)
Also, in build.properties, should the setting be:
compile.target=1.5 or 5.0 for JDK 1.5 ?
P.S. I'm off to Arofan's wedding in Arizona, and won't be back for 11
days :) I will let you know how the patch works when I get back.
On Wed, 21 Sep 2005 06:44:38 -0400, "Farrukh Najmi"
> Steve Allman wrote:
> >I'm rather embarassed to say that my omar code dates from 22/5/2005, so
> >I can't apply the patch without upgrading to latest CVS. I have to
> >support a couple of deployed registries, so I'll have to make a new
> >installation. Will the latest code runn with JDK 1.4.2 and JWSDP 1.5 or
> >do I have to upgrade?
> Latest CVS code will mostly run with JDK 1.4.2 but JDK 5 is preferred.
> It will also run with JWSDP 1.5 but JWSDP 1.6 is preferred and default.
> >On Tue, 20 Sep 2005 17:44:58 -0400, "Farrukh Najmi"
> ><Farrukh.Najmi@...> said:
> >> When removing (or deprecate/undeprecating/approving) a huge number
> >>of objects omar has a scalability issue.
> >> This was a known issue and the ebRS 3.0 spec had addressed it by
> >>adding a new AdhocQuery param to
> >>Remove/Deprecate/Undeprecate/ApproveObjectsRequest in
> >> addition to the existing ObjectRefList as follows:
> >> AdhocQuery: This parameter specifies a query. A registry MUST remove
> >>all objects that match the specified query in addition to any other
> >>objects identified by other parameters.
> >> ObjectRefList: This parameter specifies a collection of references
> >>to existing RegistryObject instances in the registry. A registry MUST
> >>remove all objects that are referenced by this parameter in addition to
> >>any other objects identified by other parameters.
> >> Omar had not been updated to use the new AdhocQuery parameter.
> >>Fix Description:
> >> The LCM methods in server for
> >>remove/deprecate/undeprecate/approveObjects where fixed to apply the
> >>following pattern.
> >> A call was made to a new method
> >>RequestContext.getObjectsRefsFromQueryResults(AdhocQueryType query) to
> >> the ObjectRefs for objects matching the query. These ObjectRefs were
> >>appended to list of ObjectRefs specified by the ObjectRefList
> >> parameter. Rest of the code is unchanged.
> >>Files Updated:
> >> src/java/org/freebxml/omar/server/lcm/LifeCycleManagerImpl.java:
> >> Fixed remove/deprecate/undeprecate/approveObjects to make use of
> >>the AdhocQUeryParameter using
> >>RequestContext.getObjectsRefsFromQueryResults(AdhocQueryType query)
> >> src/java/org/freebxml/omar/server/common/RequestContext.java:
> >> Added getObjectsRefsFromQueryResults(AdhocQueryType query) to
> >> fetch
> >> the ObjectRefs for objects matching the query.
> >> test/org/freebxml/omar/server/lcm/LifeCycleManagerImplTest.java:
> >> A new test testRemoveWithAdhocQueryAsParam() has been added for
> >>new feature.
> >> The code fix now avoids fetching entire objects aross from server to
> >>client (good)
> >> The code still has to fetch the ObjectRefs from the dbms
> >>(tens/hundreds of thousands of them) within the server (bad).
> >> This is necessary because significant processing occurs to check
> >>access control etc.
> >> A future optimization in a subsequent patch may be to use a cursor
> >>that iterates over 10000 objects (configurable)
> >> objects in each iteration.
> >> Also missing in this patch are changes to JAXR API to make this new
> >>feature usable. That will be next.
> >>Steve, please apply this patch using instructions at:
> >>And let me know how things compare from before. Please note this is an
> >>incremental step
> >>on the problem. JAXR API support will be next and further optimizations
> >>after that.