JBossDeveloper

"scott.stark@jboss.org" wrote:

"adrian@jboss.org" wrote:

We do have an interface,
...
There was a previous discuss on this problem.
The issue is basically if we don't use the OSGi version then we have
to come up with some complicated code that handles comparisons between
the different implementations when doing compareTo().
...
Of course, its probably not a real problem in practice since it is unlikely that
foo:1.0.0 uses a different version implementation to foo:1.0.1 or foo:2.0.0 :-)

VersionRange could accept a Comparator to allow for externalization of the Version compareTo.

"adrian@jboss.org" wrote:

Ok. It would probably be better to change isInRange()
to accept a comparator and configure it somewhere in the classloader
setup.

But it's one of those N^2 problems in writing comparators between
all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc.

Less pluggable (do we know what all the possible parameters will be?),
but probably easier to manage/configure would be to write
some kind of complicated Version concrete class that can handle all the different versions
and always map the other versions into it.

"scott.stark@jboss.org" wrote:

"adrian@jboss.org" wrote:

I fixed the "default package" problem...

This is the cause of some of the security test failures as they are not finding "users.properties" resources. I would expect a fair number of the 250 extra failures are related to this.

"anil.saldhana@jboss.com" wrote:

The security tests in the main testsuite still have this problem of the users.properties/roles.properties files not detected as part of the deployment.

Any guidance on this?

"adrian@jboss.org" wrote:

Although this looks wrong to me. Resources in the root of the ear
shouldn't be seen by the classloader anyway??????

$ jar -tf ~/jboss-head/testsuite/output/lib/form-auth.ear
META-INF/
META-INF/application.xml
META-INF/jboss-app.xml
META-INF/security-config.xml
form-auth-users.properties
form-auth-roles.properties
form-auth.war
jboss-service.xml

I think historically all deployment roots were in the classpath. We should add an option to enable this in the ear/war structure deployers. Are we differentiating between classes and resources in the new class loader model?

If so, I would only add the resource path.

"adrian@jboss.org" wrote:

But it's one of those N^2 problems in writing comparators between
all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc.

public interface VersionComparator<T extends Version, U extends Version>
{
 /**
 * Compare the two version impls.
 *
 * @param t T version impl
 * @param u U version impl
 * @return compare the two version impls
 */
 int compare(T t, U u);
}

 public int compareTo(Version v)
 {
 VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance();
 return registry.compare(this, v);
 }

Ales, do not want to obscure your last discussion post with Adrian.

I just want to tell you that adding a jboss-structure.xml to the AS security test deployment, got the particular tests to pass. I will need to add the structure to other deployments with the same resource(properties files) detection issue.

"anil.saldhana@jboss.com" wrote:
Ales, do not want to obscure your last discussion post with Adrian.

I just want to tell you that adding a jboss-structure.xml to the AS security test deployment, got the particular tests to pass. I will need to add the structure to other deployments with the same resource(properties files) detection issue.

"adrian@jboss.org" wrote:

"anil.saldhana@jboss.com" wrote:
Ales, do not want to obscure your last discussion post with Adrian.

I just want to tell you that adding a jboss-structure.xml to the AS security test deployment, got the particular tests to pass. I will need to add the structure to other deployments with the same resource(properties files) detection issue.

Fix it properly by placing the resources somewhere that IS in the classpath.
The root of an ear should NOT be in classpath.

I really am fed up with all this "I'll add a workaround for a workaround for a bug"
that leads to stupid code and irrelevant features rather than doing a proper job.

Fix the original bug then you don't need any of the workarounds! :-)

I need some guidance here:

I have an ear file that defines a jboss-app.xml with

<jboss-app>
 <module>
 <service>jboss-service.xml</service>
 </module>
</jboss-app>

Please ignore my last Q. I figured it out.

"alesj" wrote:

"adrian@jboss.org" wrote:

But it's one of those N^2 problems in writing comparators between
all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc.

I've taken this approach.
Since I doubt the N will be big. :-)

Adding VersionComparator:

public interface VersionComparator<T extends Version, U extends Version>
{
 /**
 * Compare the two version impls.
 *
 * @param t T version impl
 * @param u U version impl
 * @return compare the two version impls
 */
 int compare(T t, U u);
}

and a VersionComparatorRegistry singleton to keep all the known implementations.

And changing the Version class to delegate the compareTo to the registry:

 public int compareTo(Version v)
 {
 VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance();
 return registry.compare(this, v);
 }