Daniel John Debrunner wrote:
Narayanan wrote:
Jørgen Løland wrote:
I have a few questions regarding replication that would be great
to hear the community's opinion on before the 10.4 branching. The
reason for bringing this up before code freeze is that these will
have impact on existing applications if changed later.
3. Should replication be shipped in a separate JAR file? Pros and
cons as I see it:
+ Remove 65KB (unjared) of class files from derby.jar
+ Possible to have a different security policy file for replication?
- Yet another JAR file
I found the following imports in the SlaveController class.
import org.apache.derby.iapi.error.StandardException;
import org.apache.derby.iapi.store.raw.RawStoreFactory;
import org.apache.derby.iapi.store.raw.log.LogFactory;
import org.apache.derby.impl.store.raw.log.LogToFile;
If SlaveController were moved to a separate replication jar wouldn't
referencing the above classes
from derby.jar result in sealing violations? This would require
giving special
permissions for these packages in the manifest creation in build.xml
like this for example
Sealing does not hide packages from other code, does it? I thought it
only prevented other code from inserting classes into the same package.
Dan.
From Derby-2071 I can see that accessing classes from
"org.apache.derby.iapi.services.io" in another jar can cause you a
sealing violation.
Also I found
"If you try to load a class in a sealed package from another source
other than the JAR file in which the sealed package lives, the JVM will
throw a |SecurityException|."
here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the last
line in the Package sealing sub-header.
Narayanan
