Managed Properties question
I have a database bean and I'm using ConfigAdmin to allow me to make changes
to an .cfg file, and have those properties set in karaf. This is working.
Woot!!!
I've noticed that individual bundles need to be restarted in order to use
these new properties. While karaf only takes six thousandths of a second to
do this, its still an extra step my users will need to perform, and... well
we know that the weakest link in an application is the end-user so... nuff
said.
What I'd like to happen is when a property is changed in the .cfg file, and
that property is picked up and set in ConfigAdmin, to have every bundle
using that property to also update. I thought that using a managed service
would do this:
bean id=configTest class=com.test.ConfigTest
osgix:managed-properties persistent-id=myPropertyFile
update-strategy=container-managed /
property name=propertyValue value=${propertyValue}/property
/bean
However, it doesn't.
First, how is the functionality I've described supposed to be provided by
the above code?
Second, is there a better way to do this?
Third, happy holidays!
v/r,
Karafman
--
View this message in context:
http://karaf.922171.n3.nabble.com/Managed-Properties-question-tp2107407p2107407.html
Sent from the Karaf - User mailing list archive at Nabble.com.
[maven-bundle-plugin] shading version issue
When using the maven-bundle-plugin to group non-bundled or improperly bundled
packages into a new bundle, I noticed that the version number of the
resulting packages is set to 0.0.0. Is there any way to fix this? Below
is some code that should allow you to see the problem:
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.1.0/version
extensionstrue/extensions
configuration
Export-Package
bad.vendor.package1;version=0.1.2,
bad.vendor.package2;version=3.2.3,
bad.vendor.package3;version=4.3.4
/Export-Package
/configuration
/plugin
/plugins
dependenciesall the bad.vendor dependencies containing the above
packages/dependencies
This results in a file where the packages are not versioned, so when the
resultant bundle is deployed into OSGi, all of the packages are set to
version 0.0.0.
In cases where we are shading together .jar files that are no longer in
development, or .jar files from vendors that simply won't play osgi well, we
create a maven-project and create this bundle along with each versioned
release of our product. As our project grows, contracts, or changes, we
need to add or remove things from this bundle. Because the package versions
are always set to 0.0.0, there is the possibility of ClassNotFound or
constraint violations.
It would be a good idea to have a way to change the behavior of this plugin
to allow the user to set the resultant package versions, or to override the
default behavior to use the ${pom.version} for each package instead of
0.0.0.
v/r,
Mike Van (karafman)
--
View this message in context:
http://karaf.922171.n3.nabble.com/maven-bundle-plugin-shading-version-issue-tp2088176p2088176.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Placing properties files in the classpath
Ok. If I have 4 bundles that all use JMS, and they are named: myApp.bundle1 myApp.bundle2 myApp.bundle3 myApp.bundle4 Would I need 4 configuration files in etc: myApp.bundle1.cfg myApp.bundle2.cfg myApp.bundle3.cfg myApp.bundle4.cfg ? - Original Message - From: Łukasz Dywicki [via Karaf] ml-node+2060078-1778899901-228...@n3.nabble.com To: Mike Van mvangeert...@comcast.net Sent: Thursday, December 9, 2010 3:58:32 PM Subject: RE: Placing properties files in the classpath It depends on the configuration admin. Karaf uses etc directory for these configurations - eg. If you persistence id is set to com.mycompany any changes in $KARAF_BASE/etc/com.mycompany.cfg will be visible for your components. It doesn't look classpath, it looks into etc directory. That's better than classpath because operations can do changes without JAR modification. Even more fantastic is fact that your component can be notified about configuration change.. Best regards, Lukasz -Original Message- From: Mike Van [mailto: [hidden email] ] Sent: Thursday, December 09, 2010 9:42 PM To: [hidden email] Subject: RE: Placing properties files in the classpath In those cases, where does OSGi look to find the properties? And, what are the property file names? Mike Van -- View this message in context: http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath- tp2054553p2060007.html Sent from the Karaf - User mailing list archive at Nabble.com. View message @ http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060078.html To start a new topic under Karaf - User, email ml-node+930749-917263437-228...@n3.nabble.com To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060101.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Placing properties files in the classpath
We were just talking about the differences between bundles we should use as services, and bundles that simply need to be wired. In my definition, all cross-cutting concerns should be services consumed by their bundles. We also have been discussing whether or not the services should all be stateless (I beleive they should be). So, for the time being, if my bundles are all myApp.*, would a myApp.cfg file placed in the etc directory be read by all bundles whose packages start with myApp? - Original Message - From: Łukasz Dywicki [via Karaf] ml-node+2060113-309240584-228...@n3.nabble.com To: Mike Van mvangeert...@comcast.net Sent: Thursday, December 9, 2010 4:06:15 PM Subject: RE: Placing properties files in the classpath No, These bundles may reffer same persistent id (configuration file) without problems. In fact - you may introduce new bundle which produces connection factory and export it as service to reduce number of configuration dependencies. Best regards, Lukasz -Original Message- From: Mike Van [mailto: [hidden email] ] Sent: Thursday, December 09, 2010 10:03 PM To: [hidden email] Subject: Re: Placing properties files in the classpath Ok. If I have 4 bundles that all use JMS, and they are named: myApp.bundle1 myApp.bundle2 myApp.bundle3 myApp.bundle4 Would I need 4 configuration files in etc: myApp.bundle1.cfg myApp.bundle2.cfg myApp.bundle3.cfg myApp.bundle4.cfg ? - Original Message - From: Łukasz Dywicki [via Karaf] [hidden email] To: Mike Van [hidden email] Sent: Thursday, December 9, 2010 3:58:32 PM Subject: RE: Placing properties files in the classpath It depends on the configuration admin. Karaf uses etc directory for these configurations - eg. If you persistence id is set to com.mycompany any changes in $KARAF_BASE/etc/com.mycompany.cfg will be visible for your components. It doesn't look classpath, it looks into etc directory. That's better than classpath because operations can do changes without JAR modification. Even more fantastic is fact that your component can be notified about configuration change.. Best regards, Lukasz -Original Message- From: Mike Van [mailto: [hidden email] ] Sent: Thursday, December 09, 2010 9:42 PM To: [hidden email] Subject: RE: Placing properties files in the classpath In those cases, where does OSGi look to find the properties? And, what are the property file names? Mike Van -- View this message in context: http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath- tp2054553p2060007.html Sent from the Karaf - User mailing list archive at Nabble.com. View message @ http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060078.html To start a new topic under Karaf - User, email [hidden email] To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060101.html Sent from the Karaf - User mailing list archive at Nabble.com. View message @ http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060113.html To start a new topic under Karaf - User, email ml-node+930749-917263437-228...@n3.nabble.com To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Placing-properties-files-in-the-classpath-tp2054553p2060367.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Accessing database connections using SpringDM in Karaf
Problem solved! The issue was using factory-method, which required the class I called to be static. This also required that all of my properties and thier mutators be static. This resulted in my bean that passed the reference not being able to see my mutators. The fix was to have my DAOTest class implement the InitializingBean, changing the doPopulate() method to afterPropertiesSet(), and then removing all static declarations. Thanks to Joed from the IRC group for helping me figure this out. v/r, Mike Van -- View this message in context: http://karaf.922171.n3.nabble.com/Accessing-database-connections-using-SpringDM-in-Karaf-tp1932916p1993729.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Accessing database connections using SpringDM in Karaf
I think I'm almost there! WOOT!!
Karaf is giving me the following error:
org.springframework.beans.NotWritablePropertyException: Invalid property
'controller' of bean class [java.lang.string]: Bean property 'controller' is
not writable or has an invalid setter method. Does the parameter type of the
setter match the return type of the getter?
Here is my pojo:
public class DAOTest {
private static DataSourceController controller;
public static void setController(DataSourceController controller){
DAOTest.controller = controller;
}
public static DataSourceController getController() {
return controller;
}
public static String dataPopulator() {
// excercise the DAO and return pass if it passes
}
}
Here is the DAOTestContext.xml file:
bean id=DAOTest class=myApp.testharness.DAOTest
factory-method=dataPopulator
p:controller-ref=dataSourceController
/
osgi:reference id=DataSourceController
interface=myApp.controller.DataSourceControllerIfc /
And here is the DataSourceContext.xml file from the myApp.controller bundle
which creates the service in Karaf:
bean id=myAppDataSourceController
class=myApp.controller.DataSourceController
p:Dao-ref=myAppDao /
osgi:service id=dataSourceController ref=myAppDataSourceController
interface=myApp.controller.DataSourceControllerIfc/
In Karaf when I perform an ls on the myApp.controller bundle I get the
following:
Bundle id provides:
---
Bundle-SymboicName = myApp.controller
Bundle-Version = 0.0.1
objectClass = myApp.controller.DataSourceControllerIfc
org.springframework.osgi.bean.name = myAppDataSourceController
service.id = number
Does anyone have an idea what the issue is? I also noticed that when I pass
a class reference via Spring to my pojo, it wont' let me pass in Strings or
Ints. Kind of unnerving.
v/r,
Mike Van
--
View this message in context:
http://karaf.922171.n3.nabble.com/Accessing-database-connections-using-SpringDM-in-Karaf-tp1932916p1956889.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Open Ports in Karaf
Rosh, Could you please let us know how you identified that as an issue? I'd like to see if I can replicate this with Karaf 2.0 and 1.6. v/r, Mike Van - Original Message - From: Roshan A. Punnoose [via Karaf] ml-node+1870475-1529360336-228...@n3.nabble.com To: Mike Van mvangeert...@comcast.net Sent: Tuesday, November 9, 2010 11:56:56 AM Subject: Open Ports in Karaf Hi, I am trying to figure out what ports Karaf opens up. I was able to get most of them (ssh, jmx rmi, etc) except a few. Everytime Karaf starts up (v. 2.1.0) it opens up two randomly assigned ports in the high numbers. For example: 3:tcp4 0 0 127.0.0.1.57165 *.* LISTEN 4:tcp46 0 0 *.57164 *.* LISTEN If I turn off the DisableAttachMechanism flag so that jconsole cannot connect to karaf, the bottom one is gone, but the top one remains: 3:tcp4 0 0 127.0.0.1.57168 *.* LISTEN (Notice, they are different numbers because they are randomly assigned) Does anyone know why this port is opened, and how to close it? Roshan Punnoose [hidden email] Proteus Technologies View message @ http://karaf.922171.n3.nabble.com/Open-Ports-in-Karaf-tp1870475p1870475.html To start a new topic under Karaf - User, email ml-node+930749-917263437-228...@n3.nabble.com To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Open-Ports-in-Karaf-tp1870475p1870612.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle dependency visualization
There are a few karaf-command-line options which should help you: Mikes-Awesome-Karaf-Build exports bundleId Mikes-Awesome-Karaf-Build imports bundleId Mikes-Awesome-Karaf-Build exports | grep the package you want to see Mikes-Awesome-Karaf-Build imports | grep the package you want to look for Mikes-Awesome-Karaf-Build dev:show-tree I'd like to say that you can also look for imports and exports in the Eclipse debugger, but that would be a lie. So, the above stuff is what I normally use. v/r, Mike Van - Original Message - From: Andreas Gies [via Karaf] ml-node+1864727-692683097-228...@n3.nabble.com To: Mike Van mvangeert...@comcast.net Sent: Monday, November 8, 2010 2:29:49 PM Subject: Re: Bundle dependency visualization Hi Mike, thanks for this. I am aware of the Eclipse tool. However, I was wondering if something similar was there working on OSGi bundles and their manifests rather than working on pom files. For example, with the Dependency graph I wouldn't see dependencies that I have sucked into my OSGi container using the wrap: url support. Also, if I have 3rd party bundles that have not been built with maven, I would be blind to them I believe ? I was thinking along the lines of a tool that kind of relates the import/export packages of the bundles ? Thanks Andreas View message @ http://karaf.922171.n3.nabble.com/Bundle-dependency-visualization-tp1864059p1864727.html To start a new topic under Karaf - User, email ml-node+930749-917263437-228...@n3.nabble.com To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Bundle-dependency-visualization-tp1864059p1864795.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Delay a Start-level?
There are no such things as stupid questions. Just my opinion. v/r, Mike Van - Original Message - From: Kit Plummer [via Karaf] ml-node+1865644-84520632-228...@n3.nabble.com To: Mike Van mvangeert...@comcast.net Sent: Monday, November 8, 2010 5:07:36 PM Subject: Re: Delay a Start-level? Ok, sorry for the stupid questions. How do I get a hold of the ConnectionFactory provided by localhost-broker.xml via a blueprint config? Kit On Nov 8, 2010, at 1:42 PM, Guillaume Nodet wrote: Doesn't the localhost-broker.xml created by default already export a JmsConnectionFactory in the OSGi registry ? If not , you could add it there. Else, I suppose what you do is ok. On Mon, Nov 8, 2010 at 18:58, Kit Plummer [hidden email] wrote: The broker is loaded by the ActiveMQ feature - I guess by the localhost-broker.xml config...which is the last thing to load during startup (after activemq:create-broker --type blueprint is run). So I don't have a good way to expose the ConnectionFactory. I did create a local class that extends ActiveMQConnectionFactory, and then gets exported in another bundle. I put a simple loop in the start method that spins until a connection is made. But, the other bundle that actually is connecting, starts up even with or without the connection being made. So I guess the export is resolved before the start method finishes. I'm not sure this makes a lot of sense...sorry for that. I don't suppose there is some magic blueprint require that can be put in the bean definition? Kit -- View this message in context: http://karaf.922171.n3.nabble.com/Delay-a-Start-level-tp1850174p1864241.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com View message @ http://karaf.922171.n3.nabble.com/Delay-a-Start-level-tp1850174p1865644.html To start a new topic under Karaf - User, email ml-node+930749-917263437-228...@n3.nabble.com To unsubscribe from Karaf - User, click here . -- View this message in context: http://karaf.922171.n3.nabble.com/Delay-a-Start-level-tp1850174p1865819.html Sent from the Karaf - User mailing list archive at Nabble.com.
