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

[Design the new POJO MicroContainer] - Re: ProfileService shutdown and undeploy order

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | This can obviously be fixed, but I guess what should really be happening | is the ProfileService undeploys in reverse order of stages, | i.e. APPLICATION then DEPLOYER then BOOTSTRAP. | | The MainDeployer.shutdown() should just be there to catch things | that don't undeploy themselves properly. | | The problem is that the Profile api doesn't guarantee any ordering | | | Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception; | | | Certainly the phases should be undeployed in reverse order. If needed the deployments api could express ordering using a List, but should that be necessary? If it started correctly it should stop correctly unless new dependencies are being accessed during shutdown. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123624#4123624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123624

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Class loading debugging

by adrian＠jboss.org

The one issue is that this is a management api. So we need a way to identify the policy. Currently each policy has a "name" but that's just for debugging purposes. In the deployment layer we use the top level deployment name. The domains do have a unique name. Assuming the name is enough, I can see it being fairly trivial to implement a management api like the following on the ClassLoaderSystem: Assume similar api for getResources() | // Basic lists | Collection<ClassLoaderDomain> listDomains(); | Collection<ClassLoaderPolicy> listPolicies(); | Collection<ClassLoaderPolicy> listPolicies(String domainName); | | // Your point 2 - class exported in a domain | Class showClass(String domainName, String className); | ClassLoaderPolicy findClassPolicy(String domainName, String className); | | // Your point 1 - class exported by a policy | Class showExportedClass(String policyName, String className); | // Class maybe private (not exported) | Class showLocalClass(String policyName, String className); | // Class located using normal rules | Class findVisibleClass(String policyName, String className); | ClassLoaderPolicy findVisibleClassPolicy(String policyName, String className); | One issue with the showLocalClass and showExportedClass is that the policy may not actually use it, if it is in one of its imports the imports hide the class (like the uses constraint in OSGi). I also imagine we can show things like some package queries as well. Like listing who exports what package and what they are searched for exportAll. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123621#4123621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123621

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Small addition to JAXBIntroductions: Support for @XmlTra

by tfennelly

Hi Andy. That sounds great and we'd be more than happy to accept your additions. Easiest thing to do for now is to package up your changes (in an SVN patch file if possible) and attach them to a new feature request JIRA at http://jira.jboss.com/jira/browse/JBESB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123614#4123614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123614

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Class loading debugging

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I'd like to get a better view of what has visibility to a class from the system/domain level. What I would like is: | | 1. Be able to ask a policy, what policies have a resource/class | You mean locally. That's two different questions depending on whether it exports those resources/classes. I also assume you mean a domain or the classloading system? There's a different question as to whether it can see it from one of its imports or the domain if it is importAll. But that's just the standard classloading api. anonymous wrote : | 2. Be able to ask the BaseClassLoaderSystem what domains have a resource/class | That pretty much already exists, but it will only be exported classes and resources. The only part that is missing is the ability to list the domains so you can iterate over them and do loadClass/getResource. anonymous wrote : | 3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view. | There's no such thing in general. If the policy is a VFSClassLoaderPolicy then you can ask what its VFS roots are and you could ask what other policies it can see that are VFSClassLoaderPolicys or URLClassLoaders. But the new classloading system has been designed to be flexible. There's no direct dependency of URLs/VFS etc. Somebody can implement a policy how they want. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123613#4123613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123613

16 years, 11 months

1
0
0 / 0

[Design of POJO Server] - EJB/War deployer ordering problem

by pete.muir＠jboss.org

Trunk seems to be starting the war before the ejb3s are started. This causes a problem, as Seam uses a ServletListener to boot itself, and can try look up EJB3s using JNDI (as described http://docs.jboss.org/ejb3/app-server/tutorial/jndibinding/jndi.html). This is reproduced by running cd jbossas/testsuite | ./build.sh _jars-seam | cp output/lib/jboss-seam-dvd* ../build/output/jboss-5.0.0.Beta4/server/default/deploy | cd ../build/output/jboss-5.0.0.Beta4 | ./bin/run.sh You should get a NamingException from Seam, as it fails to look up the EJB3. Note, the deployment order is different if you deploy to the already running app server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123612#4123612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123612

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Small addition to JAXBIntroductions: Support for @XmlTransie

by AndyMalakov

Hello All, We had a problem mapping subclasses of java.lang.Exception in XML using JAXB 2.1. In particular, JAXB tried to map Exception.stackTrace field and failed with the following error: IllegalAnnotationsException: "java.lang.StackTraceElement does not have a no-arg default constructor". Luckily JBoss JAXBIntroductions provided us a workaround. Once I added support for @XmlTransient annotation I was able to annotate Exception with @XmlTransient in JaxbIntros meta data. (Another way may be annotating Throwable.stackTrace). Can I contribute to JaxbIntros project by submitting @XmlTransient support (XmlTransientHandler and XmlTransientIntro) into SVN? Best Regards, Andy Malakov View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123611#4123611 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123611

16 years, 11 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: transaction (crash recovery) tests.

by smcgowan＠redhat.com

Have you seen this: http://docs.jboss.org/process-guide/en/html/testsuite.html The testsuite/imports/server-config.xml has macros used to start and stop the server configs which you can look at for reference. If the intent is to test the integration of JBossTS with the AS 5, 5++, it seems that requiring them to pass if JBossTS is swapped out should not be a priority. Adding these tests would include creating a new test target and the determination of whether this test target should be executed in a certain run can be configured build.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123609#4123609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123609

16 years, 11 months

1
0
0 / 0

[Design of JBoss Build System] - Re: VFS build problem

by scott.stark＠jboss.org

I was able to do a release:prepare -DdryRun=true with the updated pom.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123605#4123605 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123605

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-232, VFSUtils.addManifestLocations

by scott.stark＠jboss.org

I don't know why we need to restrict redundant paths. Any combination of . and .. should be allowed and resolvable to the canonical form without any . or .. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123604#4123604 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123604

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ProfileService shutdown and undeploy order

by adrian＠jboss.org

The problem with the NoInitialContext in the all configuration is because it is not undeploying the in the reverse order of deployment. | 17:49:05,946 ERROR [DefaultPartition] partition unbind operation failed | javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial | at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) | at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) | at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:284) | at javax.naming.InitialContext.unbind(InitialContext.java:375) | at org.jboss.ha.framework.server.ClusterPartition.stopService(ClusterPartition.java:408) | The issue is that the ProfileServiceBootstrap just does a MainDeployer.shutdown() but this just undeploys in "random" order. | private Map<String, DeploymentContext> topLevelDeployments = new ConcurrentHashMap<String, DeploymentContext>(); | | public void shutdown() | { | lockWrite(); | try | { | while (topLevelDeployments.isEmpty() == false) | { | // Remove all the contexts | for (DeploymentContext context : topLevelDeployments.values()) | { | topLevelDeployments.remove(context.getName()); | removeContext(context, true); | } | | // Do it | process(); | } | In the example above, conf/jboss-service.xml is undeployed before the clustering deployment. This can obviously be fixed, but I guess what should really be happening is the ProfileService undeploys in reverse order of stages, i.e. APPLICATION then DEPLOYER then BOOTSTRAP. The MainDeployer.shutdown() should just be there to catch things that don't undeploy themselves properly. The problem is that the Profile api doesn't guarantee any ordering | Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception; | even though it is implemented as ordered in ProfileImpl using LinkedHashMaps | private LinkedHashMap<String, VFSDeployment> bootstraps = new LinkedHashMap<String, VFSDeployment>(); | private LinkedHashMap<String, VFSDeployment> applications = new LinkedHashMap<String, VFSDeployment>(); | private LinkedHashMap<String, VFSDeployment> deployers = new LinkedHashMap<String, VFSDeployment>(); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123603#4123603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123603

16 years, 11 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 January 2008