[Design of JBoss Build System] - Re: Improvements
by epbernard
"pgier" wrote : "epbernard" wrote : well I was more thinking about an extreme version of that. A extreme CI.
| | You take all snapshots of all projects all the time. So you see shit coming and you see when you break 95% of the app server.
| I just wanted to note that this is how maven is set up normally. It will by default check daily for updates of snapshot dependencies. And how the AS build was working until Dimitrius started locking down versions to do a release. One of the problems is that in order to do a beta or RC release of the app server the versions of the components have to be locked down otherwise you have a build that is not reproducible.
Dimitris position totally makes sense. We need a parallel run where snapshots of X.Y libs is used to build the edge version. from those results, dimitris can pick and chose who is stable and ask for a release of particular libraries.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172785#4172785
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172785
17 years, 7 months
[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an
by jesper.pedersen
I'm currently looking at this trace
| 10:42:57,675 INFO [TxConnectionManager] afterCompletion(4) isTrackByTx=true for org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@6efac385[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@40f33dde handles=0 lastUse=1219826577640 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$PoolBySubject@2162db22 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@6120a64d xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@35f8a538 txSync=null]
|
| 10:42:57,675 INFO [TxConnectionManager] returnManagedConnection=org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@6efac385[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@40f33dde handles=0 lastUse=1219826577640 permit=true trackByTx=false mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$PoolBySubject@2162db22 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@6120a64d xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@35f8a538 txSync=null]
|
| 10:42:57,701 INFO [TxConnectionManager] afterCompletion(3) isTrackByTx=true for org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@6efac385[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@40f33dde handles=1 lastUse=1219826577675 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$PoolBySubject@2162db22 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@6120a64d xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@35f8a538 txSync=null]
|
An afterCompletion() coming in wih status of COMITTED and handles=1 on the same managed connection as a previously afterCompletion() with status of ROLLBACKED and handles = 0.
I've updated the patch in the JIRA issue.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172761#4172761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172761
17 years, 7 months
[Design of EJB 3.0] - Re: Classloading problem in proxy factories
by ALRubinger
To explain the reason that TCL code is in place...
Without it, when performing web injection (which, by servlet spec, uses an isolated CL), we get:
java.lang.IllegalArgumentException: failed to set value Proxy to jboss.j2ee:ear=tx_stateful_web.ear,jar=tx_stateful_web_ejb.jar,name=StatefulTestBean,service=EJB3 implementing [interface org.jboss.ejb3.proxy.intf.StatefulSessionProxy, interface org.jboss.ejb3.proxy.intf.SessionProxy, interface org.jboss.ejb3.proxy.intf.EjbProxy, interface somepackage.RemoteIF] on field private somepackage.RemoteIFsomepackage.TxServlet.remoteBean
So even though "somepackage.RemoteIF" is implemented by the Proxy, it clashes with the destination target because the CLs are not equal.
"bstansberry" wrote : Seems like generating a Proxy class using something other than the container classloader is a classloader leak.
The interface target in a Servlet has a different CL than that of the Container, hence the different CL.
"bstansberry" wrote : Perhaps this is a sign of a classloader leak? Proxy.getProxyClass(...) is maintaining a cache of proxy classes
I'm not sure this is true, if I'm reading the source and comments from Proxy.getProxyClass correctly:
/*
| * Note that we need not worry about reaping the cache for
| * entries with cleared weak references because if a proxy class
| * has been garbage collected, its class loader will have been
| * garbage collected as well, so the entire cache will be reaped
| * from the loaderToCache map.
| */
To move forward, how about we also catch and ignore the LinkageError (to get the proxy-clustered tests passing), and I'll have to proceed with EJBTHREE-1442 to see if this is indeed the source of a CL leak.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172733#4172733
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172733
17 years, 7 months
[Design of Security on JBoss] - JACC issue: why is not Policy::implies called on my Policy p
by kcg
Hello,
I'm porting home-grown JACC provider from GlassFish to JBoss 5.0 CR1. I've copied all the needed jars into server/all/lib subdirectory. Followed http://wiki.jboss.org/wiki/JACC to enable it. When I start jboss with:
| ./bin/run.sh -Djavax.security.jacc.policy.provider=<my policy provider class> -Djavax.scurity.jacc.PolicyConfigurationFactory.provider=<my policy configuration factory provider class> -c all
|
it seems my policy provider gets called, but only by a lot of getPermissions calls. There is none implies call done, although I'm accessing protected resource of JMX JBoss console. My experience with GlassFish is a little bit different, my policy provider implies is called for every access control decision and that's also why I put main access control decision into the implies method. IMHO it should be there also following JACC spec. My question is: have I forgotten to do anything to properly configure my JACC for JBoss? Or is there any bug in 5.0 CR1 which prevents my JACC policy provider implies method to be called?
Thanks,
Karel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172698#4172698
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172698
17 years, 7 months
[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO
by ALRubinger
"jaikiran" wrote : Relying on the getName implementation of the EJBContainer (which just returns this name), results in failure of a couple of tests in the EJB Core.
This is because EJB Containers are registered with the AOP?Remoting Dispatcher by way of their ObjectName.canonicalName. @see SessionSpecContainer.registerWithAopDispatcher().
I think getName(), in the case of EJB3 Proxy, is vague. And who's to say that the Container is registered for remoting under its name (as you've shown here).
So rather than overriding getName(), let's add to InvokableContext:
String getDispatcherRegistrationName()
...which may be implemented in SessionSpecContainer:
return this.getObjectName().getCanonicalName();
...and then be called upon by SessionSpecContainer.registerWithAopDispatcher(). Then you'll have it available to you everywhere within EJB3 Proxy.
"jaikiran" wrote : The SessionContainer, is using the deprecated Ejb3Module to create a name for the container. Do you want me to change (and test) the SessionContainer to create the name as follows:
|
| super(JavaEEComponentHelper.createObjectName(deployment,ejbName), ...);
| |
|
A note about SessionContainer:
EJB3 Proxy isn't used until SessionSpecContainer (the difference being that SessionSpecContainer adheres to session beans defined by the spec, and SessionContainer can become the basis for things like @Service).
So where appropriate, I've been slowly breaking things out (and centralizing from StatefulContainer/StatelessContainer) into SessionSpecContainer to try and clean things as we go.
So let's break out the logic in SessionContainer where it constructs a container name into a "protected String constructContainerName(String ejbName)", but leave the implementation as used in the SessionContainer ctor intact.
The end result will be that the container name does not change, but you'll have all information you need from the new getDispatcherRegistrationName().
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172691#4172691
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172691
17 years, 7 months