We're going to quickly run smack into the problem where references to services like datasources are expressed in terms of JNDI names and the referencing component is being deployed before these referenced services.
What I do now is VERY VERY hacky. I take the JNDI name of the datasource and construct an Kernel name from it.
We talked before about requiring services that register in JNDI to also create a generic JndiBinding bean. Another thought I had, what about integrating/federating JNDI with the Kernel Registry?
ANyways, this should be a topic for a different thread.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992104#3992104
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992104
With respect to fleshing out the Profile Service I'm thinking about what would need to happen to deploy a DataSource into the MC using the Profile Service, e.g.
0) Start the Server
1) Use JSR88+StreamingDeployment to upload a DataSource deployment (*)
2) Have the ProfileService pass the new deployment off to the MainDeployer.
Did I miss anything? Is this about the most basic use case we can start with?
(*)Do we care about whether the DataSource gets deployed the old mbean way i.e. -ds.xml, rather than the new raw MC way, i.e. -beans.xml? I'm guessing this would be related to
http://jira.jboss.com/jira/browse/JBAS-3415 (Port RARDeployer).
These steps would seem to require the Profile Service to have the "proper deployment repository notion " Scott mentions above.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992099#3992099
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992099
One per top level deployment. You don't need a schema for the dependency as it not going to be expressed in any descriptor. Its a runtime dependency that the security deployer adds to the component that expresses the fact that the reference to the security metadata has introduced a dependency on the policy object. If a different (non-jacc) security deployer is in use because jacc is not being used, then there would be no JaccPolicy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992095#3992095
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992095
I have started/stopped Tomcat several times trying to disable Kosmos informational logging using a log4j.properties file but have given up. Can you provide details about how/where to do this?
In the process of doing the above, I noticed that Kosmos startup was getting slower. Currently the Tomcat log is 1.1GB and Kosmos now takes 10 minutes to startup. Looking back in the log, only the first startup was 5 minutes. Every startup following the first one took 10 minutes.
Any idea why that might be?
The log entries which match the following pattern are recording much longer times than they did on the first startup:
PROPFIND, 207 "Multi-Status", 1609 ms, /files/kosmos-cache
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992087#3992087
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992087