dm-serve 2.0 problem spring security dependancy breaks admin console

[jeremy]

Hi,

I noticed in the issue tracker that:

DMS-2245 was marked Complete but with no comments.
EBR-605 was marked Complete but with a comment to say this was moved to the EBR Jira.

It would allow us to move forward with dm-server, as we want to use Xalan for other things beside CAS.

Regards,

Jeremy.

[cgfrost]

Hi,

Sorry for the delay getting back to you, this one slipped past us for a few days.

We have had another look at this problem and have a different solution for you to try.
This was done on dm Server 2.0.1 but it should work just as well on 2.0.0 if you are still on that.

Copy the following bundles from the EBR to the usr repo,

com.springsource.org.apache.xalan-2.7.1.jar
com.springsource.org.apache.xerces-2.9.1.jar
com.springsource.org.apache.xml.resolver-1.2.0.jar
com.springsource.org.apache.xml.serializer-2.7.1.jar
com.springsource.org.apache.xmlcommons-1.3.4.jar

Then edit the lib/java6-server.profile file to add the following line in the boot delegation section near the bottom.

org.apache.xalan.*,\

Note that the pattern can't go any deeper in to the package as osgi will not match this against 'org.apache.xalan.Foo' for example. It is strictly a package pattern and the '*' will not match any classes or the package 'org.apache.xalan' as it expects the package name to be extended by the '*'.

With this in place, clean start the server (-clean option) and everything should start as expected and just work as normal. In the admin console you will see that the xalan bundles you provided are loaded and thanks to boot delegation they are just avaliable for use. You do not need to import the xalan packages/bundles etc... In fact if you do things will start to break.

To prove to youself that this is working there is a sample app attached to https://issuetracker.springsource.com/browse/DMS-2245 that you can deploy. All it dose is load a Transformer factory and display it's class on a web page. Have a look at it's source and see it has no package or bundle imports for it. As such you will not be able to see any wirings for it in the OSGi state browser, this is because there arn't any.

The only downside to this approach is that you loose the ability to have multiple versions of xalan around. You are bypassing the OSGi classloading approach by using boot delegation.

Let me know if this is of any help.
Chris.

[koxo]

Chris, I have tried your solution, but it didn't work for me.

I have modified dmserver/lib/java6-server.profile by adding org.apache.xalan.* to org.osgi.framework.bootdelegation and put the following to dmserver/repository/usr:

com.springsource.org.apache.xalan-2.7.1.jar
com.springsource.org.apache.xerces-2.9.1.jar
com.springsource.org.apache.xml.resolver-1.2.0.jar
com.springsource.org.apache.xml.serializer-2.7.1.jar
com.springsource.org.apache.xmlcommons-1.3.4.jar

After starting dm server with -clean option and accessing http://localhost:8080/xalan/, I get this:

javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found

Also splash/admin apps are suffering from the same problem. I am attaching both profile and log.

[cgfrost]

Hi,

OK, this is a little odd now. Before I plow through the logs etc... could you just confirm for me the Java version, dm Server version and operating system you are using.

Thanks, Chris.

Sorry, could you also check your manifest has no imports for any xalan stuff, although the admin and splash apps should be working with this set up.

[koxo]

I get this deploying your org.eclipse.virgo.sample.xalan.war download from the JIRA issue.

I am using dm server 2.0.1.RELEASE, Java(TM) SE Runtime Environment (build 1.6.0_19-b04) and Win XP SP3.

[cgfrost]

Hi,

It would seem OS is the difference, I can recreate what you are describing on XP but not Mac, we use Macs day to day for dev work. I have dug a little deeper and have an improved fix for you.

In the java profile file, as well as adding the extra line, change the xerces line so it reads as follows.

 org.apache.xalan.*,\
 org.apache.xerces.*,\

Finally, instead of copying those apache jars to the repository/use directory, place them in the lib directory instead. Now the entire server will be using these instead of the ones that come with Java.

I have had this working on XP so hopefully you will be good to go now.

Chris.

[koxo]

That seemed to have helped. Both /xalan and /admin contexts are working now.

However, there are some bundles in repository/usr I use in my app which import package org.apache.xpath and these are not resolved during startup. Here's the list:

com.springsource.flex.messaging.common-3.2.0.3978.jar
com.springsource.flex.messaging-3.2.0.3978.jar
com.springsource.org.apache.activemq-5.3.0.jar
com.springsource.org.apache.derby-10.5.1000001.764942.jar

Does it mean these have to be fixed not to import that package?

[cgfrost]

Hi,

Glad to hear it. You are correct about the other bundles, they can not import that packages as technically nothing exports them. They will need to be modified. This can actually be automated to make like a little easier. Using Bundlor, http://www.springsource.org/bundlor . You can give it your modified Java profile and it will crack open the jar and re-write the manifest for you. Seeing is this is the tool used for everything in the EBR to start with it should get it right.

Chris.

[koxo]

The question in my mind really is whether profile in dm server distribution should be modified and also all bundles in EBR

[cgfrost]

A valid point certainly. In your situation it would deffinetly be the right thing to do. We don't however what to make all other uses of dm Server use a different version of the XML transformers and associated code to the one provided with Java. The question then would be what version and I'd bet my hat that several uses would request different versions all for seemingly good reasons.

I think the ideal solution would be some extra code that keeps an eye out for meta-inf/services definitions and adds the appropriate bundles to the classpath but that would be opening a can of worms I don't want to think about right now. Doing such things at runtime would not be easy.

Chris.