OSGi: Capturing the current request

[Maarten Daalder]

Hello,

We have code that needs to access the current request (to determine the host and similar), however this seems to be a bit tricky when in a Dynamic plugin.

The problem is when you have code that still needs to work when accessed from outside the /app/ part, normally we would use a listener (ServletRequestListener) for this purpose, however, that is only called when the Bridge/Proxy servlet of Apache Felix is hit.

Similarly, request-bound viewtools are only created a velocity context is required.

Our target is making configuration more managable between server environments (Development, Integration, Production, etc, etc), however, this includes all aspects that are also dependent on the PluginAPI interface, which we override. And in that case we might not always have a viewtool or a request through the Apache Felix bridge.

What would you suggest to always make the current request available?

With kind regards,
Maarten Daalder

ISAAC

[Falzone, Chris]

I don't know much about the dynamic plugin part of this, but if you are talking about a viewtool, you can pass the request object in the viewtool's methods.  This is usually what I do, so I can make my viewtools application scoped and still have access to the request object.  

--
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
Visit this group at http://groups.google.com/group/dotcms.
For more options, visit https://groups.google.com/groups/opt_out.

--

Christopher Falzone

Interactive Developer

A Q U E N T

Digital, Creative, and Marketing Talent

aquent.com

cfal...@aquent.com

[Maarten Daalder]

Hi Chris,

My specific problem is during the override of the PluginAPIImpl class, that way I can hook into everything, except I can't add parameters, and it wouldn't be completely transparent to any current use-site of the PluginAPI.

With kind regards,

Maarten Daalder

ISAAC

[Jason Tesser]

Not sure what you mean by having problems with the pluginAPIImpl.  If you mean you don't know how to replace our class you should just override it in a plugin. Static plugin is the safest way here. In a dynamic plugin you are dealing with order in which we construct classes in the system 

For the request maybe create a filter or something in a static plugin. You need to get it first in the chain probably so you might have to override the entire web.xml in the ROOT directory of the plugin. 

This isn't great because you will probably need to alter your plugin every version but it would do the trick.  In the filter store the request in the session or something. 

[Jason Tesser]

I guess not the session but like a threadlocal or a publicly available static reference 

[Maarten Daalder]

Hi All,

I've managed to get the request, the custom rewrite rule wasn't initializing properly.

However, now the problem is overriding classes, trying to override PluginAPIImpl with a class that implements PluginAPI (with the same name and in the same package) I get the following error:

[16/10/13 15:16:34:555 CEST] ERROR osgi.ConfigurationActivator: Error injecting context for overriding

java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment

at sun.instrument.InstrumentationImpl.addTransformer(InstrumentationImpl.java:88)

at com.dotmarketing.osgi.UrlOsgiClassLoader.<init>(UrlOsgiClassLoader.java:47)

at com.dotmarketing.osgi.GenericBundleActivator.injectContext(GenericBundleActivator.java:291)

at com.dotmarketing.osgi.GenericBundleActivator.injectContext(GenericBundleActivator.java:258)

at com.dotmarketing.osgi.GenericBundleActivator.publishBundleServices(GenericBundleActivator.java:141)

at nl.isaac.dotcms.plugin.configuration.osgi.ConfigurationActivator.start(ConfigurationActivator.java:31)

at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)

at org.apache.felix.framework.Felix.activateBundle(Felix.java:2146)

at org.apache.felix.framework.Felix.startBundle(Felix.java:2064)

at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1483)

at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:334)

at java.lang.Thread.run(Thread.java:722)

[Jason Tesser]

I think this was a bug on a older version. Are you on 2.5?

[Maarten Daalder]

Yes.

This is the generated manifest, also shows my JDK, I'm running startup.bat from the commandline (in Windows):

Manifest-Version: 1.0

Bnd-LastModified: 1381929314236

Build-Jdk: 1.7.0_17

Built-By: Maarten

Bundle-Activator: nl.isaac.dotcms.plugin.configuration.osgi.Configuratio

 nActivator

Bundle-ClassPath: .,isaac-dotcms-libconfiguration-2.5-1-SNAPSHOT.jar,isa

 ac-configuration-1.1.7.jar,commons-configuration-1.9.jar,commons-beanut

 ils-1.8.3.jar,commons-logging-1.1.1.jar,slf4j-api-1.6.4.jar,jcl-over-sl

 f4j-1.6.4.jar,log4j-1.2.16.jar,commons-lang-2.6.jar

Bundle-DocURL: http://www.isaac.nl

Bundle-ManifestVersion: 2

Bundle-Name: isaac-dotcms-configuration

Bundle-SymbolicName: nl.isaac.dotcms.plugin.configuration.isaac-dotcms-c

 onfiguration

Bundle-Vendor: ISAAC Software Solutions

Bundle-Version: 2.5.0.SNAPSHOT

Created-By: Apache Maven Bundle Plugin

Data-Files: conf,ext

DynamicImport-Package: *

Embed-Dependency: *;scope=compile|runtime;inline=false

Embed-Transitive: true

Embedded-Artifacts: isaac-dotcms-libconfiguration-2.5-1-SNAPSHOT.jar;g="

 nl.isaac.dotcms.plugin.configuration";a="isaac-dotcms-libconfiguration"

 ;v="2.5-1-SNAPSHOT",isaac-configuration-1.1.7.jar;g="nl.isaac.comp";a="

 isaac-configuration";v="1.1.7",commons-configuration-1.9.jar;g="commons

 -configuration";a="commons-configuration";v="1.9",commons-beanutils-1.8

 .3.jar;g="commons-beanutils";a="commons-beanutils";v="1.8.3",commons-lo

 gging-1.1.1.jar;g="commons-logging";a="commons-logging";v="1.1.1",slf4j

 -api-1.6.4.jar;g="org.slf4j";a="slf4j-api";v="1.6.4",jcl-over-slf4j-1.6

 .4.jar;g="org.slf4j";a="jcl-over-slf4j";v="1.6.4",log4j-1.2.16.jar;g="l

 og4j";a="log4j";v="1.2.16",commons-lang-2.6.jar;g="commons-lang";a="com

 mons-lang";v="2.6"

Export-Package: nl.isaac.dotcms.plugin.configuration;uses:="nl.isaac.dot

 cms.plugin.configuration.api";version="2.5.0.SNAPSHOT",nl.isaac.dotcms.

 plugin.configuration.api;uses:="com.liferay.portal,org.osgi.framework";

 version="2.5.0.SNAPSHOT",com.dotmarketing.plugin.business;uses:="nl.isa

 ac.dotcms.plugin.configuration,nl.isaac.dotcms.plugin.configuration.api

 ,com.dotmarketing.portlets.fileassets.business";version="2.5.0.SNAPSHOT

 "

Import-Package: com.dotmarketing.filters,com.dotmarketing.osgi,com.dotma

 rketing.plugin.business,com.dotmarketing.portlets.fileassets.business,c

 om.liferay.portal,org.osgi.framework;version="[1.7,2)"

Override-Classes: com.dotmarketing.plugin.business.PluginAPIImpl

Tool: Bnd-1.50.0

[Maarten Daalder]

Well, I managed to prevent the exception. In my activator I have calls to both initializeServices and publishBundleServices, however, if I move the publish call to be above the initialize call then the Exception does not occur.

Unfortunately, the desired effect is still not present.