October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: WarDeployer dependency on TomcatClusteringCache

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : A similar situation exists with the JBossContextConfig in that the authenticators should be declared directly on it rather than propagated from the WarDeployer via jmx. How we work around this in the interim of tomcat supporting injection of pojos is a todo. | Yes, unless tomcat allows injection, there is limited flexibility with reference to JBossContextConfig. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982200#3982200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982200

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: WarDeployer dependency on TomcatClusteringCache

by scott.stark＠jboss.org

What I am saying is that these should not be expressed as dependencies on the WarDeployer. They are the defaults for dependencies that one would describe in a jboss-web.xml. To start the war deployer I don't need any of these other services. So this: | <bean name="WarDeployer" class="org.jboss.web.tomcat.tc6.deployers.TomcatDeployer"> | ... | <property name="securityManagerService"> | <inject bean="jboss.security:service=JaasSecurityManager" /> | </property> | <depends>jboss.cache:service=TomcatClusteringCache</depends> | | <depends>jboss:service=TransactionManager</depends> | |  | </bean> | should be something like: | <bean name="WarDeployer" class="org.jboss.web.tomcat.tc6.deployers.TomcatDeployer"> | ... | <property name="defaultSecurityManagerService">jboss.security:service=JaasSecurityManager</property> | <property name="defaultCacheService">jboss.cache:service=TomcatClusteringCache</property> | <property name="defaultTM">jboss:service=TransactionManager</property> | | </bean> | These would then be added to each WebMetaData depends list. We need to update the WebModule mbean to expose accessors for these services so that the dependency can be injected and the WebModule can perform the related configuration. This is the minimal necessary refactoring of the WarDeployer. The CachedConnectionValve should be the one expression the injection of the CachedConnectionManager. A similar situation exists with the JBossContextConfig in that the authenticators should be declared directly on it rather than propagated from the WarDeployer via jmx. How we work around this in the interim of tomcat supporting injection of pojos is a todo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982198#3982198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982198

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: WarDeployer dependency on TomcatClusteringCache

by bstansberry＠jboss.com

That gets us back to the original issue then -- declaring in the WarDeployer bean a dependency on the TomcatClusteringCache causes the start of the AS to fail due to a missing dependency, I believe before the VFSDeploymentScanner is even created/started. The WarDeployer bean also has a commented-out dependency on CachedConnectionManager. If that were uncommented, I expect the same problem would arise. In both that and the ClusteredSSO case, it's not the webapp that has the dependency; it's the embedded Tomcat service itself. Is a deployer installed via the deployers dir meant to be allowed to have a dependency on a bean installed from the deploy dir? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982195#3982195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982195

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: WarDeployer dependency on TomcatClusteringCache

by scott.stark＠jboss.org

Ok, I was confused about what I ended up with. The org.jboss.web.tomcat.tc6.deployers.WarDeployer should just be deleted as it was an early local prototype. org.jboss.web.deployers.AbstractWarDeployer is the base AbstractSimpleRealDeployer that is creating the ServiceMetaData for the web app mbeans in deployWebModule. This is passing on the jboss-web.xml dependencies to the web app ServiceMetaData. There are a lot of refactoring to be done once tomcat itself is better broken up, but for now the only problem is that the dependencies declared on the WarDeployer should really be propagated down to the web application mbean. So the war-deployer-beans.xml should just have the names of the beans/services that satisfy the tm, clustering, security, etc. needs, and these should just be added to the WebMetaData depends list for processing by the service layer. How these services are injected/accessed is likely going to need to be pushed down into the web app mbean as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982185#3982185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982185

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: why javasist and jboss retro

by david.lloyd＠jboss.com

"tom.baeyens(a)jboss.com" wrote : is it worth this hassle ? Maybe, maybe not. I do feel somewhat more comfortable using the RI, but I can't say I have a real reason for it. Possibly because I have had some conversations with several core developers and I feel more comfortable with reporting problems than I do with MyFaces. "tom.baeyens(a)jboss.com" wrote : please, focus on bringing the repository up to date with the referenced jar files. I am doing so right now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982177#3982177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982177

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: WarDeployer dependency on TomcatClusteringCache

by bstansberry＠jboss.com

Currently the WarDeployer bean is o.j.w.t.tc6.deployer.TomcatDeployer, which is combining the functions of starting the embedded Tomcat itself and of deploying webapps. If I understand Adrian correctly, he's saying these functions should be separated. That certainly seems cleaner and will eliminate the dependency issue with ClusteredSSO. Scott, you mention WarDeployer.performDeployInternal -- looks like that class is a pure deployer. Is the plan to switch over to that class, which would allow us to deploy tomcat itself via the DeploymentScanner? The WarDeployer would then need to add a dependency on the embedded Tomcat service itself to any TomcatDeployment mbean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982171#3982171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982171

18 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: How to stop application code access to JBoss system/serv

by krishc

Thanks for your reply. 1. So we can stop an Appication user from loading a Jboss system/sensitive class through Loader.loadClass(..),Class.forName(..), Foo.class etc once we turn on security manager ? 2. I am guessing this will be done with java2.policy only and no changes to the loader heirarchy ? Krish View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982162#3982162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982162

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by clebert.suconic＠jboss.com

"timfox" wrote : This is a good point, and one that I covered in the design WIKI page: http://wiki.jboss.org/wiki/Wiki.jsp?page=NewHADesignOverview (see the end of the page) | | Transferring queues back to a node if it recovers is a very difficult thing to do. Since consumers may be connected to the queues on the new node we can't just move them back to the old node. | | Theoretically this is possible by effectively failing them over again to the original node, however in this case any non persistent messages unacked in their sessions will get redelivered so this is not acceptable, if the sessions have any unacked np messages. | | This makes the whole thing complex, too complex to do initially. Eventually, if we decide to implement this it could also be used in the general case for the redistribution of connections across the cluster to best utilise available resources. But this is a nice to have and the pain to gain ratio is very high. I'm concerned on a scenario where a client reconnects back into serverA. A failed consumer will use the nodeID as part of the key of the subscriptionID (by either implementing subscriptionName containing nodeId or by changing PostOffice's signatures the way I have done). Let me explain of an example: I - Client connects into serverA II - Client creates durable subscriber (named subA) III - serverA fails IV - ServerB assumes subA V - Client decided to disconnect from server (session.close()) VI - ServerA comes back. VII - Client reconnects back (into serverA) VIII - Clients creates durable subscriber (named subA)... this won't give back the same channelID as nodeB would have the channel now. This could mean loss of messages. In a parallel scenario... I - Client connects into serverB II - Client creates durable subscriber (named subA (same name)) III - It won't use the same channelID as the one created from serverA as the original nodeId is different So... serverB will have two subscriptions... one from failed nodeA and another from nodeB. subscriptionA on serverB will be only accessible when serverA fails, and if the client reconnects back to serverA its queue won't be available there. One thing that I thought to solve this was transfering the queue back on serverA once serverA is back. If that's not possible maybe we could implement dependency between queues. Say.. the local queue would consume messages from the failed queue (with the same name) case the queue is empty. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982161#3982161 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982161

18 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: How to stop application code access to JBoss system/serv

by scott.stark＠jboss.org

Run with a security manager so that the security sensitive code permission checks can be enforced. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982157#3982157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982157

18 years, 2 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: DeploymentUnit access to parent

by scott.stark＠jboss.org

You have to do this through the deprecated DeploymentContext currently. There should just a getParent accessor on the DeploymentUnit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982156#3982156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982156

18 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006