November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Portal Development] - The Struts dispatcher cannot be found

by DimasTejero

Hello, We are migrating an application based on Spring, Struts2 and Hibernate, from Tomcat application server to JBOSS 5. We have already resolved problems about library dependencies, but we are facing error about using struts2 filter, because JBOSS is not able to to link each request: (The Struts dispatcher cannot be found. This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag) The application runs ok on Tomcat and also on JBOSS4. Thank you very much in advance. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266402#4266402 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266402

16 years, 4 months

1
0
0 / 0

[jBPM Development] - iPhone / iPod Touch access to jBPM tasks

by aapthorp

I thought you may be interested... Thanks to the eTask http://www.apptism.com/apps/etask iPhone app I've found that I can access jBPM tasks from an iPhone / iPod Touch using my taskcal CalDav wrapper. Viewing tasks should work with taskcal0.1. Full update functionality is anticipated in the forthcoming taskcal0.2. I couldn't believe how easy this was... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266400#4266400 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266400

16 years, 4 months

1
0
0 / 0

[JBoss AS Development] - Re: JBAS-7469, move bootstrap class loading into profile

by ALRubinger

EmbeddedAS is a bit of a different beast. Currently it has a mega-JAR of all AS dependencies bundled for users to put on the ClassPath. Looking forward I need to intelligently trim this down so that user tests can still use the APIs without leaking internals and resulting in NoClassDefFoundError when AS comes up. So in effect, when AS starts up in Embedded mode, all classes are loaded from the application CL. >From the perspective of the bootstrap project, ClassLoading is removed from scope entirely except for this bit which Adrian has wanted to move out for some time: http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-base... @startBootstraps() ...where we rely upon the CL which loaded the bootstrap to start processing its referents. Everything else is set up by Main in phases (appCL slim run.jar, then we add a custom URLCL with a bunch of things necessary to start the server). ShrinkWrap won't be at all affected. But let me know if you run into more specific issues. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266395#4266395 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266395

16 years, 4 months

1
0
0 / 0

[JBoss AS Development] - JBAS-7469, move bootstrap class loading into profile

by scott.stark＠jboss.org

The last piece of the legacy conf/jboss-service.xml that needs to be removed in order for the profile bootstrapURI to be dropped along with this service descriptor is the: |  | <classpath codebase="${jboss.server.lib.url}" archives="*"/> | <classpath codebase="${jboss.common.lib.url}" archives="*"/> | I think this sould be part of the profile definition metadata and the current bootstrapURI processing replaced with the setup of a class loader bean deployment. I wanted to look more at the current bootstrap/embedded/shrinkwrap projects to what requirements exist along these lines. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266390#4266390 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266390

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Getting rid of conf/jboss-service.xml

by scott.stark＠jboss.org

I just commited the initial change where all services have been moved out of conf/jboss-service.xml as the smoke-tests are passing. This bootstrap descriptor is still needed for the bootstrap class loader. To completely remove conf/jboss-service.xml, the bootstrap class loader configuration also needs to be moved into the profile. JBAS-7469 is tracking this and I'll start a separate thread on that. The services in conf/jboss-service.xml have been moved into: deployers/core-naming-jboss-beans.xml - the basic bean and remote access bean deploy/naming-jboss-beans.xml - legacy mbean wrapper and jndi view (which needs updating) deploy/legacy-conf-service.xml I think there is more work to make the naming service more usable as a mcbean such as moving the remoting piece from deployers/core-naming-jboss-beans.xml to deploy/naming-jboss-beans.xml and making better use of the remoting v3 for the remoting proxy. I'm going to look at what the requirements from the embedded usecases were before doing anything along these lines. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266387#4266387 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266387

16 years, 4 months

1
0
0 / 0

[JBoss AOP Development] - Re: ClassPool Refactoring

by flavia.rainone＠jboss.com

Kabir has provided me feedback on this in private. He thinks that, overall, the integration is good to be ported to trunk. I'll post here the points he addressed in our private chat. These are the points that need to reviewed: 1. The field ClassPool classPool of Instrumentor should be of type AOPClassPool. 2. I should see if I can find a workaround for checks such as the one below: if (this.childFirstLookup != delegate.childFirstLookup) | { | delegate.childFirstLookup = this.childFirstLookup; | } This check is there because childFirstLookup is a public field of ClassPool. AOPClassPool uses ClassPool as a delegate, so it can delegate to any classpool of jboss-classpool project. However, to force AOPClassPool and ClassPool to work consistently, I added these checks. This will be reviewed, but we are both afraid that maybe there is no solution for this. 3. Should ClassPoolRepository.callback be a list instead? I've made it a reference to a single callback for performance reasons. I can change it if Kabir or Ales prefer. 4. Maybe we should rename ClassLoaderRepository to avoid confusion with ClassPoolRepository class. 5.In (AOP)VFSClassLoaderDomain, instead of the initMapsDone and cleanupLoaderDone methods, I could just override initMaps() and cleanupLoader() directly in AOPVFSClassLoaderDomain, call the super method and add the "Done" stuff at the end. Kabir pointed out that this may be not so simple as it looks because I need some local variables from those methods. I'm going to work on these points before porting the changes to trunk. Notice that I'll have to check if the tests are still passing and do any adaptation needed on the 742 branch... This can be done only after the classpool project is estabilized and the vfs tests are passing ok. Those tests are the subject of another thread. http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265325#4265325 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266376#4266376 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266376

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: New features in classloading

by david.lloyd＠jboss.com

Do any of these changes have negative performance implications? For example it looked like the changes for JBCL-128 might introduce some significant overhead. Might be worth doing some before/after profiling just in case? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266375#4266375 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266375

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: How does bundle resolution work

by adrian＠jboss.org

Discussion and update on missing features in jboss-cl http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163957 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266368#4266368 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266368

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Bug in Microtainer - recursive resoltion

by adrian＠jboss.org

I found a bug yesterday while doing the 'lazy resolve" feature for the classloading. The issue is that we avoid recursive processing of a ControllerContext by adding them to the "installing" Set inside AbstractController. But this only traps invocations of install/uninstall. If a recursion occurs during the checking that dependencies are resolved, it goes into recursive death with a StackOverFlowException. I'm going to change the mechanism such that while dependencies are being resolved the context is also added to "installing". In fact, if the dependencies are resolved, it should stay there, rather than rebuilding this from the "resolvedContexts". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266367#4266367 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266367

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: New features in classloading

by adrian＠jboss.org

I'm aware of a few other missing features in the classloading which I haven't yet raised JIRA issues for, although JIRA already exist for some. 1) Allow optional imports on wildcards 2) Allow dynamic imports on wildcards 3) Permission checks to use Capabilities 4) Allow fragments - i.e. additions to the "classpath" of a classloader 5) Extension bundles - i.e. hot deployment (but not undeployment) into the "bootstrap classpath" 6) Circular dependencies 7) Split packages I think (4) would be better implemented in the deployers by allowing one deployment to dynamically become a subdeployment of another one. But this still requires a mechanism to augment the classpath roots in the VFSClassLoaderPolicy. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266364#4266364 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266364

16 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009