June 2008 - jboss-dev-forums - Jboss List Archives

[Deployers on JBoss (Deployers/JBoss)] - Re: BaseClassLoader attachement makes DeploymentUnit non-ser

by dimitris＠jboss.org

I'd think that serialVersionUIDs make really sense after we reach a GA status and people actually depend on the serialization compatibility. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157386#4157386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157386

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: BaseClassLoader attachement makes DeploymentUnit non-ser

by scott.stark＠jboss.org

"dimitris(a)jboss.org" wrote : | BTW, why switching to serialVersionUID = 1? | Because it was an incompatible change to remove a serial field. Even though the only time this could be serialized was when the loader field was null. Because the serial format for the class changed I changed the serialVersionUID. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157380#4157380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157380

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Installing instance of wrong class gives weird error

by alesj

"wolfc" wrote : It should then check whether the declaring class is assignable from the target class. I'll add this check to ReflectionUtils: | protected static void checkMember(Object target, Member member, String memberType) throws Throwable | { | if (member == null) | throw new IllegalArgumentException("Null " + memberType); | | if (target != null) | { | Class<?> declaringClass = member.getDeclaringClass(); | if (declaringClass.isInstance(target) == false) | throw new IllegalArgumentException("Target (" + Strings.defaultToString(target) + ") doesn't match " + memberType + " 's (" + member + ") declaring class."); | } | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157372#4157372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157372

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: BaseClassLoader attachement makes DeploymentUnit non-ser

by dimitris＠jboss.org

Hm, although the issue is marked as fixed in Beta18 yesterday (June 10th), Beta18 was release on June 4th. The jboss-metadata project in JIRA needs a good cleanup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157356#4157356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157356

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: BaseClassLoader attachement makes DeploymentUnit non-ser

by dimitris＠jboss.org

Thanks Scott. I see jboss-trunk is using metadata 1.0.0.Beta18 that contains the JBMETA-52 fix, but the serialization problem is still there? BTW, why switching to serialVersionUID = 1? http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/metadata/trun... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157348#4157348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157348

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: EAR Dependency

by adrian＠jboss.org

I assume for this discussion that this is JBoss-4.x The issue with making the EAR something that can be depdended on is quite complicated. There are three basic competing issues that make it difficult. * The EAR represents a total view of all its component's state This is not true now. The EAR MBean has no relationship with the other mbeans that are part of the deployment. This would require that the EARDeployment.start() lifecycle is not invoked until all the other mbeans that are in the EAR (ejb modules, ejb containers, web containers, datasources, -service.xml, etc.) are in the started state. This could only be achieved by collecting all the mbean names in the create() lifecycle stage and adding dependencies to the ear mbean. With that done, then the EAR mbean would become what this feature request requires. i.e. you add a depends tag somewhere else and guarantee that everything in the ear is in the started state. * The EAR Deployment for management operations Almost the exact opposite of this feature request is that you could consider that invoking EAR.stop() on the JMX console would stop all its components. This would require that rather than the EAR dependening on its components, the components would have to depend on the EAR MBean. * The EAR Deployment as a place for two stage initialisation of per deployment state The current usage of the EAR isn't as a service, but as something tied to the SubDeployer lifecycle. Again this is create/start/stop/destroy but it is not the service lifecycle. There is no dependency. The subdeployment lifecycle is just invoked on all the (sub)-deployments with the order determined by the prefix ordering and "russian doll" semantics. For the EAR it is this: | public void start(DeploymentInfo di) | throws DeploymentException | { | super.start (di); | try | { | // Commit the top level policy configuration | PolicyConfiguration pc = (PolicyConfiguration) | di.context.get("javax.security.jacc.PolicyConfiguration"); | pc.commit(); | Policy.getPolicy().refresh(); | serviceController.start(di.deployedObject); | } | catch (Exception e) | { | DeploymentException.rethrowAsDeploymentException("Error during start of EARDeployment: " + di.url, e); | } | log.info ("Started J2EE application: " + di.url); | } | In this case, the EAR's start transition is used to initialise the shared Jacc policy that has been collected from the subdeployments. If this is not done in the correct order because of dependencies then the components that use the policy are likely to fail due to the policy being in an invalid state. I think that is happening in JBAS-3664? But somebody with more knowledge of Jacc would need to investiage that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157332#4157332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157332

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by dimitris＠jboss.org

You shouldn't see the problem now with the upgrade to jboss-common-core 2.2.7.GA. Or if you do, that should happen with any previous version of JBoss. If there is still a problem, then a solution should be found in the re-writing of some vfs/deployment logic to reduce the usage of URLs/URLConnections. Or remove the URL abstraction layer in VFS and deal with files directly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157331#4157331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157331

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alesj

"alex.loubyansky(a)jboss.com" wrote : Ok, commit it. It's IncludeTestCase in MC's deployers-vfs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157312#4157312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157312

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Installing instance of wrong class gives weird error

by wolfc

Installing an instance into MC while specifying another class in the bean meta data yields: java.lang.IllegalArgumentException: Wrong arguments. start for target org.jboss.ejb3.stateful.StatefulContainer@1f8f8c8 expected=[] actual=[] instead of: java.lang.IllegalArgumentException: object is not an instance of declaring class (The last one could also use some decoration.) ReflectionUtils should actually have the method as context parameter and not just the name. It should then check whether the declaring class is assignable from the target class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157310#4157310 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157310

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alex.loubyansky＠jboss.com

Ok, commit it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157308#4157308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157308

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008