|So... if virtual host = security domain, do we also have a classloader
|(ServiceLibrary/Scope type thing) for it? Is this the same as the
That is how I understand it from Scott's email but maybe he means something
else in which case the mapping is not that straight-forward
|application classloader or is it the parent classloader of the application
|classloader?
The system classloader is always the parent of the application class loader.
I remember someone in London making a case for unification of both... I
don't see it anymore, we will see in the future, for now, keep them separate
with system (rh) parent to app (scoped)
marcf
|
|
|More comments interspersed.
|
|On 2001.09.19 16:50:56 -0400 Scott M Stark wrote:
|> I've been looking at how to include virtual hosts for wars, ejbs and rars
|> that need to bind their exported interfaces to specific addresses. Also
|> needed
|> is a notion of a security domain for the KeyStore if you need to use
|> SSL/TLS
|> with
|> the exported transport. The security domain could also be used for
|> authentication
|> and authorization of users, principal mapping, single sign-on, etc.
|Certainly an rar needs some security support, but what interface would one
|export that is bound to an address?
|
|>
|> Right now there are serveral notions of deployers, not all of which are
|> well
|> defined by an interface. There is a base DeployerMBean that is
|> implemented by the J2eeDeployer and RARDeployer, but it is not used by
|> the
|> EJB deployer(ContainerFactory) or the WAR deployers(EmbeddedTomcat,
|> EmbeddedJetty).
|> Rather there is an assumption about the signature of deploy made by the
|> J2eeDeployer
|> for the JarDeployerName and WarDeployerName mbeans it uses. There is also
|> no
|> unified notion of security at the deployer level. EJBs and WARs based
|> security off of
|> jboss.xml and jboss-web.xml descriptors. RARs have another notion of
|> security
|> at the ConnectionFactoryLoaderMBean level.
|>
|> I would like to come up with an application domain notion that combines
|> all
|> deployers,
|> auto deploy directories, virtual host interface and security into a logic
|> collection of
|> resources and application components with a common interface address and
|> security
|> domain. Effectively all of the mbeans in an application domain become
|> contained
|> mbeans within the application domain. For example,
|>
|> <mbean code="org.jboss.deployment.J2eeApplication"
|> name="Default:service=J2eeApplication">
|> <attribute name="DomainName">Default</attribute>
|> <attribute name="VirtualHost">localhost</attribute>
|> <attribute name="SecurityDomain">java:/jaas/localhost</attribute>
|> <attribute
|name="JarDeployerName">:service=ContainerFactory</attribute>
|> <attribute
|name="WarDeployerName">:service=EmbeddedCatalina</attribute>
|> <attribute name="RarDeployerName">:service=RARDeployer</attribute>
|>
|> <mbean code="org.jboss.ejb.ContainerFactory"
|> name=":service=ContainerFactory">
|> <attribute name="VerifyDeployments">true</attribute>
|> <attribute name="ValidateDTDs">false</attribute>
|> <attribute name="MetricsEnabled">false</attribute>
|> <attribute name="VerifierVerbose">true</attribute>
|> <attribute name="BeanCacheJMSMonitoringEnabled">false</attribute>
|> </mbean>
|> <mbean code="org.jboss.catalina.EmbeddedCatalinaServiceSX"
|> name=":service=EmbeddedCatalina" >
|> <attribute name="WebAppsRoot">webapps</attribute>
|> </mbean>
|> <mbean code="org.jboss.resource.RARDeployer"
|> name="JCA:service=RARDeployer" />
|>
|> <mbean code="org.jboss.resource.ConnectionManagerFactoryLoader"
|>
|>
|name=":service=ConnectionManagerFactoryLoader,name=MinervaNoTransCM
|Factory">
|> <attribute name="FactoryName">MinervaNoTransCMFactory</attribute>
|> <attribute name="FactoryClass">
|> org.jboss.pool.connector.jboss.MinervaNoTransCMFactory
|> </attribute>
|> <attribute name="Properties"></attribute>
|> </mbean>
|>
|> <mbean code="org.jboss.resource.ConnectionFactoryLoader"
|> name="JCA:service=ConnectionFactoryLoader,name=MinervaDS">
|> <attribute name="FactoryName">MinervaDS</attribute>
|> <attribute name="RARDeployerName">:service=RARDeployer</attribute>
|> <attribute name="ResourceAdapterName">
|> Minerva JDBC LocalTransaction ResourceAdapter
|> </attribute>
|> <attribute name="Properties">
|> ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:1476
|> </attribute>
|> <attribute name="ConnectionManagerFactoryName">
|> MinervaSharedLocalCMFactory
|> </attribute>
|> <attribute name="ConnectionManagerProperties">
|> # Pool type - uncomment to force, otherwise it is the default
|> #PoolConfiguration=per-factory
|> # Connection pooling properties - see
|> # org.jboss.pool.PoolParameters
|> MinSize=0
|> MaxSize=10
|> Blocking=true
|> GCEnabled=false
|> IdleTimeoutEnabled=false
|> InvalidateOnError=false
|> TrackLastUsed=false
|> GCIntervalMillis=120000
|> GCMinIdleMillis=1200000
|> IdleTimeoutMillis=1800000
|> MaxIdleTimeoutPercent=1.0
|> </attribute>
|> </mbean>
|>
|> <mbean code="org.jboss.ejb.AutoDeployer" name=":service=AutoDeployer">
|> <attribute name="Deployer">:service=J2eeApplication</attribute>
|> <attribute
|> name="URLs">../deploy/default,../deploy/default/lib</attribute>
|> </mbean>
|> </mbean>
|>
|> All services within a J2eeApplication domain would inherit the
|> J2eeApplication domain
|> name as their JMX ObjectName domain component. All services would be
|> associated
|> with the security domain of the J2eeApplication domain.
|
|OK, but haven't you left out the configuration of the security domain? For
|instance, the ConnectionFactoryLoader security stuff seems to have
|disappeared. I don't see right off how you could easily separate principal
|mappings from their ConnectionFactories-- it seems to me that one
|application might use 5 ConnectionFactories each with an incompatible
|PrincipalMapping.
|
|>
|> A similar domain notion would need to be added to the 3.0 RH services
|> configuration.
|>
|> An alternative is to simply add VirtualHost and SecurityDomain notions to
|> the
|> common ServiceMBean interface for example, and use naming conventions to
|> achieve the same effect.
|
|I think being able to deploy/undeploy sars or *service.xml into a
|preexisting VirtualHost/SecurityDomain is desirable. How about having a
|"universal deployer" that sets up the VirtualHost/SecurityDomain, that must
|be deployed first, and then anything it allows (services, rars, ears, wars,
|whatever) can be deployed into it based on their VirtualHost/SecurityDomain
|attributes. Having the mbeans separate rather than enclosed seems to me
|offhand as if it would make immediate and delayed deployment more similar
|and simpler. On the other hand...Enclosing the sets of mbeans in one
|element provides a convenient "set" of mbeans to deploy together in the
|configure/init/start cycle. How about... the enclosing element just
|specifies the domain, virtual host, and security domain, and all the
|deployers are contained mbeans? Then you can require that all mbeans be in
|an enclosing element, which defines a deployment set.
|
|
|>
|> Another alternative is to have multiple instances of JBoss running, one
|> for
|> each
|> domain with the configuration name defining the domain with a
|> multi-domain
|> launcher.
|>
|> I'm looking for comments and suggestions on how to do this.
|
|Would each application have its own jndi namespace? (internally the app can
|only see its own jndi stuff, externally you go to 1099 on the virtual host
|ip address and deal with its security?)
|
|Thanks!
|
|david jencks
|
|>
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> https://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|>
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
