Apache Jackrabbit - Override Jackrabbit configuration parameters when deployed in Glassfish v3 - java

I feel like an idiot, but where/how do I override the Jackrabbit configuration parameters when deployed in Glassfish v3? I've tried setting rep.home in the Glassfish Admin -> Enterprise Server -> System Properties panel, but it doesn't seem to have any affect.
Do I have the property name correct?
Is this not the right place to do
this?
BTW - I'm using the Jackrabbit release bundled with the Sling API.

The Jackrabbit Configuration Parameters indicated by your link are automatically set by the Jackrabbit Repository implementation when reading the repository.xml configuration file.
What you can do to relocate the Jackrabbit Repository inside Sling is either set the "sling.repository.home" framework property (of the OSGi framework into which Sling is deployed).
Alternatively you can edit the Repository Server configuration in the Web Console Configuration Manager page. Select the configuration labeled something like org.apache.sling.jcr.jackrabbit.server.SlingServerRepository.XXX where "xxx" looks like UUID string. In that configuration change the Repository Home path. Please note, though, that this will not move your existing repository directory but just tell Sling to use a different location.

Related

how to add a parameter to spring project before <projectname>/login and after <localhost>:<portnumber> without hardcode?

I'm working on a Spring MVC project. When I run the application the URL is:
http://localhost:8080/insureYou/login
but I want:
http://localhost:8080/contextroot/insureYou/login
Is there any way of doing it without hardcoding?
In a spring-boot project you can set the context-root by specifying the following property in the application.properties file:
server.servlet.context-path=/yourcontextroot
Without spring-boot, it depends on the webserver and Tomcat offers a number of options.
I would personally opt for a META-INF/context.xml file in your war file containing the necessary information but you can also include the information in the server.xml file or in a ROOT.xml file.
See the following links for further guidance:
How to set the context path of a web application in Tomcat 7.0
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
https://www.baeldung.com/tomcat-root-application
This type of deployment however sometimes is handled separately, through an Apache server reverse-proxy or through URL rewriting.
I recommend you ascertain whether this type of need is already taken care of by your company's deployment procedures, as you may not need to deal with it at all.

Can i create separate properties file for Virgo OSGi bundle?

I have Tomcat Virgo Server. I am deploying couple of OSGi bundles. I want to expose settings through properties, so the service within bundle can read it though Java System.getProperty(String) API. Is it possible ?
You should use OSGis ConfigurationAdmin for doing this. You can deploy your properties files into [VIRGO_HOME]/pickup and then consume the properties from ConfigurationAdmin Service over the configurations pid. Virgo recognizes your properties files in its pickup folder and automatically exposes them over the ConfigurationAdmin Service. You could also list your properties files in a plan file if you use plans to deploy your bundles as an application.
Please refer to the official documentation on the Virgo Documentation Page [1] for further details.
And if you are using Spring/Blueprint you can stick to the property placeholder as you are used to. Just use the osgix namespace handlers and do something like this:
<osgix:cm-properties id="cmProps" persistent-id="com.xyz.myapp">
<prop key="host">localhost</prop>
</osgix:cm-properties>
As by default the persistent-id or pid is the name of your properties file. For further reference have a look at Gemini Blueprint Documentation as well [2].
[1] http://www.eclipse.org/virgo/documentation/virgo-documentation-3.6.4.RELEASE/docs/virgo-programmer-guide/htmlsingle/virgo-programmer-guide.html#developing-applications-configuration-artifacts
[2] http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/compendium.html#compendium:cm

Glassfish 3 with JPA configuration

I have use JPA with Hibernate in a standalone application but now I want to try with with an application server. I know GlassFish provides EclipseLink implementation for JPA but I have a few questions.
Do I need to specify in persistence.xml EclipseLink as a provider for my persistence-unit?
Does persistence.xml look the same as if it the application would not be deployed? If it does not look the same how does it look?
Do I need to specifically download the implementation jars for EclipseLink and build with them or does the container handles this after my application is deployed?
How do I specify the jdbc driver in persistence.xml?
Does my application need to be deployed as a .ear?
You don't need to specify the persistence provider, by default the one contained in your application server will be used (if it has at least the Web profile, of course, otherwise servers such as Tomcat won't provide you EclipseLink).
Yes, it will have the same look (in both applications you are just using JPA the same way).
For your code to compile, you will only need to have persistence-api.jar in your classpath (if you use Maven, set the scope to "provided"). Then the server will automatically provide its implementation jars.
You could use a persistence unit like described in this page ("typical configuration in a Java SE environment"). But I would rather suggest you use a <jta-data-source> instead, that refers to a datasource provided by GlassFish.
As far as I can tell, it can also be a WAR file, I didn't have any problem deploying it (webapp as a Maven WAR module + beans in a JAR module).

Is it possible to connect an existing JCR repository to Liferay?

I'm wondering if I can setup liferay to use my existing JackRabbit repository via com.liferay.documentlibrary.util.JCRHook
If I set all these properties to match my repository, would it work ?
jcr.workspace.name=liferay
jcr.node.documentlibrary=documentlibrary
jcr.jackrabbit.repository.root=${liferay.home}/data/jackrabbit
jcr.jackrabbit.config.file.path=${jcr.jackrabbit.repository.root}/repository.xml
jcr.jackrabbit.repository.home=${jcr.jackrabbit.repository.root}/home
jcr.jackrabbit.credentials.username=none
jcr.jackrabbit.credentials.password=none
The repository is mostly about nt:file - nt:content with nt:resources that has "jcr" and mixin properties. I'm not interested in those, I just need the files in repository to be accessible via Liferay's document library.
I'd like to avoid using CMIS integration and do it like this.
Unfortunately for now, you can only connect an existing repository via CMIS. So that your repository has to be running on a server with cmis server support, into which your repo is bound to.
There is a proposition going on, you can vote up here.

How do I slim down JBOSS?

We're using Jboss, but we are really only using its JMS stuff. So, is there a way that I can trim down what's loaded when Jboss starts?
You can go for a servlet container (Tomcat) + a JMS provider (ex. ActiveMQ), without using an application server at all.
From 6 years ago, here's a blog entry about configuring JBoss with "just the right stuff."
I haven't used JBoss in a few years, but in v4.0, you could just drop the desired jar files into the deployment directory, and JBoss would load... only those jars.
The correct way to do this, is making a separate profile on your JBoss server that contains only the things needed to use JMS. JBoss v5 comes standard with several profiles: minimal, default, standard, all and web. Each of those starts other services. If you do not specify any profile, you're using the "default" profile.
You can create your own profile starting from a copy of the minimal profile and adding services as needed for JMS support.
The JBoss documentation contains a bit of information on what the files in those profile directories are used for. See Jboss server configurations.
You didn't specify which version of JBoss that you are using. Keep in mind that there are some changes in the configuration between JBoss v4 and JBoss v5/6. The referenced documentation in the answer from Cheeso points to JBoss v4.

Categories

Resources