[jboss-user] [Clustering] - Tibco Ems Cluster - JBoss MQ
JBoss - 4.2.3.GA We are trying to deploy an application that was previously not clustered into a clustered environment. The application has heavy usage of tibco ems with both consumers and producers. When initially configuring the system, we used the wiki document on integrating JBoss with TibcoEms. The problem now seems to be in enabling the singleton jms for the consumers. I am not entirely sure which portion of the configuration would need to go into deploy-hasingleton/jms versus deploy/jms. The setup for clustered jms suggests that all of the configuration go into deploy-hasingleton/jms which causes only the first node started to be able to find the queues. Adding the configuration to deploy/jms allows everything to start appropriately, however we then have multiple consumers trying to connect to tibco ems, which is not expected. The clustering documentation states that we should configure a shared persistence provider for the queues. Is this used to enable JBoss to determine which of the consumers ( node ) is active? We did not configure the persistence for jms as tibco is handling this functionality. I am not quite sure what additional information to provide. Is this supported? Should the configuration be split between the deploy-hasingleton/jms and deploy/jms? A pointer to which configurations I need to modify/provide would be greatly appreciated and my apologies if this does not make perfect sense. Thanks in advance. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4255396#4255396 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4255396 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Persistence provider suggestions needed.
We have implemented a Custom JPA EntityManager, yes we are either masochists and/or not very bright. The real reason behind this endeavor is that operations on entities (CRUD) actually occurs via xml messaging with a number of services. So, the EntityManager manages creation of the correct message for the operation called on the given entity. For the most part, implementing the JPA spec made sense. Developers can work with either our EntityManager or the one provided by Hibernate with little transition time. However, there were some things that did not correlate properly to what we needed and we did not want to force something that may end up confusing to developers. Queries were the first thing, and are simply just not supported. Transactions are a little stranger, the concept is somewhat the same but different enough that using the Transaction API would be confusing. So what we have instead is a Bundle, a bundle conceptually works the same as a transaction but differs in! that what we are actually doing is sending a number of XML messages bundled into a wrapper message. The receiving service will then perform the operations within a single transaction. This all works pretty well, so far. Now we are to the point of integrating this with Seam. So, we have an EntityManagerFactory, an EntityManager and a Session ( yes, we modeled this after Hibernate; does that make us genius' ). What we do not have is a persistence unit, which does not really map to a host and port number. What we would like to do is have Seam manage the EntityManager/Session and possibly the Bundles. Our thoughts are that we may have to wrap our Bundle in a transaction implementation for either JPA or Hibernate. But, we are not sure if we can get around not having a persistence unit defined. We are slo unsure if we can try to mirror the Hibernate managed context in Seam or if we need to implement all of the JPA requirements and have Seam manage the JPA persistence provider. What is the easiest and/or best way to do this? Any suggestions, pointers or comments are appreciated. Thanks in advance. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4107144#4107144 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4107144 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Ejb reference in Glassfish
I am trying to get an application up and running in Glassfish that currently
works in JBoss.
Seam 2.0 Beta 1
The deployed ear file is milton-core.ear
In the web.xml file I have the following
!-- JEE5 EJB3 names --
ejb-local-ref
ejb-ref-namemilton-core/Authenticator/local/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
milton.service.security.IAuthenticator
ejb-linkAuthenticator/ejb-link
/ejb-local-ref
!-- copied from the jee5 example. Do we need this? --
ejb-local-ref
ejb-ref-namemilton-core/EjbSynchronizations/local/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
org.jboss.seam.transaction.LocalEjbSynchronizations
ejb-linkEjbSynchronizations/ejb-link
/ejb-local-ref
My ejb definition
@Stateless
@Name( authenticator )
public class Authenticator implements IAuthenticator
{
@PersistenceContext
protected EntityManager entityManager;
@In
MiltonIdentity identity;
@EJB
private IUserSvcuserSvc;
public boolean authenticate()
...
}
The Local interface
@Local
public interface IAuthenticator
{
public abstract boolean authenticate(
);
}
The entry from components.xml
core:init jndi-pattern=milton-core/#{ejbName}/local debug=true/
security:identity authenticate-method=#{authenticator.authenticate}/
Did I miss a step here?
Thanks in advance for any help.
The stacktrace
[#|2007-11-13T11:45:00.237-0600|SEVERE|sun-appserver9.1|javax.enterprise.resource.webcontainer.jsf.application|_ThreadID=15;_ThreadName=httpSSLWorkerThread-8080-0;org.jboss.web.jsf.integration.serialization.JBossSerializationProvider;_RequestID=d2b49476-b23a-408d-a569-a5e9bcb9d389;|JSF1037:
The specified SerializationProvider implementation
'org.jboss.web.jsf.integration.serialization.JBossSerializationProvider' cannot
be loaded.|#]
[#|2007-11-13T11:45:06.971-0600|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=16;_ThreadName=httpSSLWorkerThread-8080-1;|2007-11-13
11:45:06,971 55938 [httpSSLWorkerThread-8080-1] ERROR
org.jboss.seam.security.jaas.SeamLoginModule - Error invoking login method
org.jboss.seam.InstantiationException: Could not instantiate Seam component:
authenticator
at org.jboss.seam.Component.newInstance(Component.java:1853)
at org.jboss.seam.Component.getInstance(Component.java:1756)
at org.jboss.seam.Component.getInstance(Component.java:1723)
at org.jboss.seam.Component.getInstance(Component.java:1717)
at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:60)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
at org.jboss.el.parser.AstValue.getTarget(AstValue.java:34)
at org.jboss.el.parser.AstValue.invoke(AstValue.java:95)
at
org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
at
org.jboss.seam.security.jaas.SeamLoginModule.login(SeamLoginModule.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at org.jboss.seam.security.Identity.authenticate(Identity.java:331)
at org.jboss.seam.security.Identity.authenticate(Identity.java:321)
at org.jboss.seam.security.Identity.login(Identity.java:237)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
at
org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at
org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:31)
at
[jboss-user] [JBoss Seam] - Re: Ejb reference in Glassfish
My eyes deceived me.
Changing
core:init jndi-pattern=milton-core/#{ejbName}/local debug=true/
To
core:init jndi-pattern=java:comp/env/milton-core/#{ejbName}/local
debug=true/
as per the jee5 example gives me the following stacktrace. Did I miss something
else??
[#|2007-11-13T12:24:15.554-0600|SEVERE|sun-appserver9.1|javax.enterprise.resource.webcontainer.jsf.application|_ThreadID=16;_ThreadName=httpSSLWorkerThread-8080-1;org.jboss.web.jsf.integration.serialization.JBossSerializationProvider;_RequestID=d92c0cee-a95e-4424-b3c8-4130bb755823;|JSF1037:
The specified SerializationProvider implementation
'org.jboss.web.jsf.integration.serialization.JBossSerializationProvider' cannot
be loaded.|#]
[#|2007-11-13T12:24:20.882-0600|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=16;_ThreadName=httpSSLWorkerThread-8080-1;|2007-11-13
12:24:20,866 77734 [httpSSLWorkerThread-8080-1] ERROR
org.jboss.seam.security.jaas.SeamLoginModule - Error invoking login method
org.jboss.seam.InstantiationException: Could not instantiate Seam component:
authenticator
at org.jboss.seam.Component.newInstance(Component.java:1853)
at org.jboss.seam.Component.getInstance(Component.java:1756)
at org.jboss.seam.Component.getInstance(Component.java:1723)
at org.jboss.seam.Component.getInstance(Component.java:1717)
at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:60)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
at org.jboss.el.parser.AstValue.getTarget(AstValue.java:34)
at org.jboss.el.parser.AstValue.invoke(AstValue.java:95)
at
org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
at
org.jboss.seam.security.jaas.SeamLoginModule.login(SeamLoginModule.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at org.jboss.seam.security.Identity.authenticate(Identity.java:331)
at org.jboss.seam.security.Identity.authenticate(Identity.java:321)
at org.jboss.seam.security.Identity.login(Identity.java:237)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
at
org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at
org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:31)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.core.SynchronizationInterceptor.aroundInvoke(SynchronizationInterceptor.java:32)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:106)
at
org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151)
at
org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87)
at
milton.util.MiltonIdentity_$$_javassist_19.login(MiltonIdentity_$$_javassist_19.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
[jboss-user] [Security JAAS/JBoss] - Looking for some insight/advise on predetermining authorizat
Reading through the faq's on security as well as documentation on different
forms of security, I have not seen any references to complex authorization
pre-checks. I was hoping to get some insight, as I am not an expert in this
area and may have missed the reference.
We have implemented service based security, meaning the restraints on
authorization are placed on specific services and or domain objects in the
application. Authorization checks work well and are much the same security
implemented in JAAS/JBoss. The problem is actually in determining whether a
principal has permissions to a resource prior to the actual call being made.
As a scenario:
A domain object Person.
Our ACL would be something like
Read
Update
Create
Delete
From the UI perspective this is a pretty simple thing to do. In JSF/Seam we
can dynamically enable/disable the update button based on the ACL of Person
given the Principal. If we add another domain object, say Location, and it
also has an ACL then permission checks would be based on both the ACL of
Person and Location. That is assuming that a single button would result in the
operation on both domain objects. As you can see, adding services that make
use of domain objects and/or other services, can become quite complicated. In
addition, any links to this page would not be enabled if the principal did not
pass at least one of the authorization checks for all of the actions that
could be performed on that page. The thought is that there is no reason to
present a link to the page, when the user cannot even read a Person or
Location.
We are now in the beginning stage of migrating our application to a component
based architecture using Seam and JSF. This will entail creating reusable
components that would encapsulate the security pre-checks. So the problem is
defining what domain objects a component is directly making use of as well as
what other components that are directly being made use of. Following the
definition chain to each domain object and nested component, we can derive a
concrete list of domain objects to check for permissions.
I first thought that I would create an annotation that would define what
secured operations that the method performed. The code could then be scanned at
start up to determine the list of domain objects that should be checked given a
starting definition and following the chain to other definitions, then ending
at a domain object that authorization could be performed on. The problem with
this solution is the definition of what operations are being performed.
In a purely fictitious example we have a screen that makes use of a component
to find a person by name. It would allow the input of an address and register
the located person with that address. To access this screen the user should
have permission to the Find Person service, create a Location and call the
Register service.
The code may look something like this:
| public class RegisterPersonAction
| {
|@In FindPersonSvc findPersonSvc;
|@In Location location;
|@In RegisterPersonSvc registerService;
|Person person;
|
|@SecReg( FindPersonSvc.class, findPersonByName )
|public Person findPerson( String name )
|{
|person = findPersonSvc.findPersonByName( name );
|}
|
|@SecReg( Location.class, create )
|public void createLocation()
|{
|location.create();
|}
|
|@SecReg( RegisterPersonSvc.class, registerPerson )
|public void registerPerson()
|{
|registerService.registerPerson( person, location );
|}
| }
|
| public class FindPersonSvc
| {
| @SecReg( Person.class, read )
| public Person findPersonByName( String name )
| {
| ...
| }
|
| }
|
|
| public class RegisterPersonSvc
| {
| /**
| * This service is itself secured.
| */
| public void registerPerson( Person person, Location location )
| {
| ...
| }
|
| }
|
|
The problem with this approach is that any of these methods could be
overridden, making the registration non-unique. In order to make this approach
work each method that could be annotated would have to have a unique name. A
name could be added to the annotation, but this seems to be getting to be too
verbose and against the original intention, which is simplicity for developers
and easy maintenance. An alternative would be to actually scan the call chain,
in much the same way as a profiler, looking for paths that end in a secured
operation. But, this could be too time consuming to do at startup.
This, finally, leads me to the reason for my post. I started wondering if I had
missed some standard solution for this problem, or if someone might have some
insight or advise. How does one predetermine permissions across a complex graph
of components that make use of secured services or domain
[jboss-user] [JBoss Seam] - A few issues.
My apologies if these issues have already been fixed/mentioned.
1.) org.jboss.seam.mock.BaseSeamTest
|
|protected void startJbossEmbeddedIfNecessary() throws
DeploymentException, IOException
|{
| if ( !started )
| {
| Bootstrap bootstrap = Bootstrap.getInstance();
| bootstrap.bootstrap();
| started = true;
| if ( resourceExists(seam.properties) )
| {
| bootstrap.deployResourceBase(seam.properties);
| }
| if ( resourceExists(META-INF/components.xml) )
| {
| bootstrap.deployResourceBase(META-INF/components.xml);
| }
| if ( resourceExists(META-INF/seam.properties) )
| {
| bootstrap.deployResourceBase(META-INF/seam.properties);
| }
| }
|}
|
The call to deployResourceBase will only locate the first resource?
or should this be:
|
|
| @Override
| protected void startJbossEmbeddedIfNecessary(
| ) throws DeploymentException, IOException
| {
| Bootstrap bootstrap;
| if ( !started )
| {
| bootstrap = Bootstrap.getInstance();
| bootstrap.bootstrap();
| started = true;
| if ( resourceExists( seam.properties ) )
| {
| bootstrap.deployResourceBases( seam.properties );
| }
| if ( resourceExists( META-INF/components.xml ) )
| {
| bootstrap.deployResourceBases(META-INF/components.xml );
| }
| if ( resourceExists( META-INF/seam.properties ) )
| {
| bootstrap.deployResourceBases(META-INF/seam.properties );
| }
| }
| }
|
|
|
2.) org.jboss.seam.framework.Identifier
The equals method checks for an instance of the derived type
org.jboss.seam.framework.EntityIdentifier
3.) It doesn't appear as though we can use injection in base classes. Am I
mistaken? Is this a design decision?
We have gotten around this by retrieving the components programatically, i.e.
Component.getInstance( entityManager );
This means that for testing I have to load the container, when I only need
hibernate; or I have to do a check in by base class before retrieving the
component to ensure the application context is active.
Thanks for all the work.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4073542#4073542
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4073542
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: A few issues.
anonymous wrote : I will try to put a patch in for this if I can get a moment to update from cvs. Never mind, you already fixed it. :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4073583#4073583 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4073583 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: A few issues.
1.) Thanks 2.) Here is the JIRA issue http://jira.jboss.com/jira/browse/JBSEAM-1794 I will try to put a patch in for this if I can get a moment to update from cvs. 3.) anonymous wrote : I don't know what you mean by a base class. By base class I mean a base class we code for our application. Something similar to the EntityHome framework. We have a base abstract business object where we wrap the functionality of entities and an entity manager. We have something similar for entity queries and other service based code. For both cases we can do a large portion of the work in the base class, but that requires an entity manager. anonymous wrote : But Seam injection only occurs in classes annotated @Name. This sort of the point, in most case it would not make sense to have a base class be a named component, and it cannot be if it is abstract. Seam checking for annotations in the base class(es) of the component would make things easier, but if it was a design decision to not do so then that is fine and I can make use of what ever api's are available. I was merely curious as to if it was something that has just not been added yet or was never planned to be available. Thanks again. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4073581#4073581 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4073581 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Problem with Hibernate sessions post-Seam2 migration
Richard, Did you find a solution to the datasource not being bound? I am running into the same problem. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4065100#4065100 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4065100 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Context listener
As a learning/debug helper I am trying to catch events when components are
stored/removed from any context. org.jboss.seam.preSetVariable and the like do
pretty much what I am looking for, but I would like to set this in a more
coarse grained manner. As it is now, to use this I need to create a method for
each event and for each variable I want to catch an event on. I would like to
declare the components I want to catch events on and receive the events on the
same listener.
I could programatically add the observer when I see a component I am interested
in but when the method is called I will not know which component it is for as
there is no parameter passed to these methods.
As an example if I have the following:
| @Name( personAction )
| @Scope( ScopeType=PAGE )
| public class PersonAction implements Serializable
| {
| @In( scope=ScopeType.SESSION )
| Person person;
|
| ...
| }
|
And a listener something like:
| public presetVariable( Event someEvent )
| {
| log.debug( Event variable: + someEvent.getVariable() );
| log.debug( Component: + someEvent.getComponent() );
| log.debug( Contect type: + someEvent.getContextType() );
| }
|
If somehow, in a yet determined way, I configure this component as an Observer
for my event. I would like notification of when personAction and person
have been added to context and removed from context and which context that is.
I am not sure if there is already a means to do this, so any insight is
appreciated.
Thanks.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4048023#4048023
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4048023
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - 1.2.1 GA -- Split deployments
I have been trying to split the registration example into 2 non-nested/root level deployments ( war and ear ). So far this has been unsuccessful and it appears as though the reason is that the loading of the jboss-seam.jar kicks off the seam deployment scanner. This means that it should be deployed with components. The problems is that war deployments are done prior to ear deployments and since it requires the SeamListener web deployment fails because it is also in jboss-seam.jar. Searching the forums on this gives me nothing, but I find it hard to believe someone hasn't asked this before, most likely in some other words. Is this possible with Seam 1.2.1GA? My first thought was to pull out the servlet package and put it into a jboss-seam-web.jar but it looks as though that may turn out to reference much of core. Thanks in advance for any insight. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4039262#4039262 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4039262 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Deploying seam app along side standard jsf app problem
From http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration anonymous wrote : | With nested modules, only the top level file may specify class loader scoping. If you have a .ear file containing other modules, only scoping specified in the .ear's META-INF/jboss-app.xml is used. This also applies for any other deployment which contains sub-deployments. For example, if a .sar contains a .war deployment, only the .sar META-INF/jboss-service.xml scoping has effect. | I took this as meaning that if you specify a loader at the ear level, any loader specified in a nested war or sar will be ignored. If you specified the loader in jboss-app, then all of contents of the ear should be loaded within the same classloader. You can see what jars are loaded within your specified classloader by checking the jmx-console; just search for your unique-archive-name. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4038880#4038880 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4038880 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Pros/Cons of war vs. ear deployments (Jboss 4.2)
I pointed out Exadel only because I was just trying it out. The server publish action calls into a generated ant script that bundles and moves the file to the deploy directory. I believe this is actually a part of jst or wst? Really the point of the comment is that having the ability to do hot deployments of code and only the code that has really been modified is/would be a huge productivity boost for us. This is more important on the ui/web side then the back end services. I did not mean to point a finger at any specific tool, only making a generic comment about what our shop needs. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4038589#4038589 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4038589 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [The Lizzard's corner] - JavaOne 2007 - JBoss Reception?
Will ther be one this year? Haven't heard anything and have really enjoyed it the times I have gone. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4038590#4038590 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4038590 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Pros/Cons of war vs. ear deployments (Jboss 4.2)
With applications having 500k+ lines of code, it is very important to us to shrink the amount of time it takes to code/test/redeploy. We have had success in the past with deploying the ejb's in an ear file and hot deploying the web components in an exploded war outside of the ear; the ejb components are tested outside of the container. Just starting to look at seam, but it appears as though this may be troublesome to say the least. It seems as though most IDE solutions are fine with small applications where packaging and deployment times are negligible, but not very useful for large applications. Exadel?s solution fits into this category. Just my 2 cents. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4038021#4038021 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4038021 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
