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

[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB

by deruelle_jean

nevermind I found it in jboss-5.0.0.GA/lib with the same name... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201395#4201395 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201395

17 years, 2 months

1
0
0 / 0

[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB

by alex.loubyansky＠jboss.com

Just replace jboss-xml-binding.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201394#4201394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201394

17 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - Re: Get window name or page name

by rivetlogic

Hi, Note: This applies to JBoss Portal 2.6.x. I haven't tried with 2.4.x. I am also using FacesContext since this is for a JSF portlet. You should be able to get the window and page names using the JBossRenderRequest like so: // Get render request object that contains needed info | JBossRenderRequest req = | (JBossRenderRequest) FacesContext.getCurrentInstance() | .getExternalContext().getRequest(); | | // Extract window name for this portlet | String windowName = req.getPortalNode().getName(); | | // Extract page name for this window | String pageName = req.getPortalNode().getParent().getName(); I also have a blog entry that shows how to get the portal name if you're interested. Here's the link: http://blogs.rivetlogic.com/aelnattar/2009/01/12/how-to-get-the-jboss-por... Hope this helps, --Alaaeldin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201393#4201393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201393

17 years, 2 months

1
0
0 / 0

[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB

by deruelle_jean

Which JBoss AS 5 jar(s) should I replace to put the new jboss-xml-binding.jar? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201392#4201392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201392

17 years, 2 months

1
0
0 / 0

[Design of JBoss Labs] - Re: Broken Link: JBoss Portal 2.7.0 QuickStartGuide PDF

by thomas.heute＠jboss.com

oups, thanks ;) Fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201390#4201390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201390

17 years, 2 months

1
0
0 / 0

[Design of JBoss Labs] - Broken Link: JBoss Portal 2.7.0 QuickStartGuide PDF

by Grexe

is: http://docs.jboss.com/jbportal/v2.7.01/quickstartGuide/pdf/QuickStart_Gui... should be: http://docs.jboss.com/jbportal/v2.7.0/quickstartGuide/pdf/QuickStart_Guid... Tested with fixed link, works. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201389#4201389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201389

17 years, 2 months

1
0
0 / 0

[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB

by alex.loubyansky＠jboss.com

Yes. Here is an example from the test http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jbo... True is the default. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201385#4201385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201385

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Plague of temp VFS files and OOM on redeploy

by alesj

WRT - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147622&start=20 I already did some changes, but they are not solving all the problems users face. The problems: (1) expire of VFS cache entries lead to plague of temp files (2) the temp files are never deleted (3) re-deploy causes OOM on VFS code What I did and/or what is still to do: (1) I added Combined VFS cache where part of it is permanent entries (most common roots), the other part is real cache - any of the VFSCache impls (2) I'm currently looking into the issue, eventually closing VirtualFileHandler when it's no longer used e.g. in FileHandler update --> closing cached/old child handlers Current code keeps a ref track on VirtualFileHandler usage, only to allow close when ref == 0. But in FileSystemContext we keep root's VirtualFileHandler ref from the beginning. | /** A reference to the virtual file of the root to stop it getting closed */ | private VirtualFile rootFile; | | public VirtualFileHandler getRoot() throws IOException | { | if (root == null) | { | root = createVirtualFileHandler(null, file); | if (root == null) | throw new java.io.FileNotFoundException((file == null ? "<null>" : file.getName()) | + " doesn't exist. (rootURI: " + getRootURI() + ", file: " + file + ")"); | | rootFile = root.getVirtualFile(); | What's the purpose of this? (see comment/usage) This prevents me from closing something like this: - my.ear/ui.war/lib/tools.jar Where I would want to close my.ear's VirtualFile ref, eventually closing all nested entries -- actually also deleting its matching temp files. The new code to ZipEntryContext does that: | public void close(ZipEntryHandler handler) | { | VirtualFileHandler rootHandler = getRoot(); | if (rootHandler.equals(handler)) | { | getZipSource().close(); | // only close nested - as they might be temp files we want to delete | for (VirtualFileHandler vfh : nestedHandlers) | { | vfh.close(); | } | } | } | (3) I only got this via user feedback, hence not really tested And like the users says, the real cause might be elsewhere. But Marko promised to have a look anyway. :-) The user also notes that this wasn't an issue in previous JBossAS versions. But after starting small internal discussion I'm no longer persuaded that that's really true, as I didn't get any (internal) feedback that would point me to some real proof that we actually did things any different, different from File.deleteOnExit or deleting temp at boot time. It might be just the simplicity of what we did before that resulted in things working. Looks like that what might work for users, doesn't quite work for us yet - simplicity vs. VFS's API. But we'll get there. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201380#4201380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201380

17 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : | | Having a getModuleForClass() would make sense. | | Why would you want it to return multiple modules? | | I might have misunderstood, I just noticed that it is possible to have several DelegateLoaders. If it can return just one, all the better. | There's multiple delegates because you can have multiple imports. anonymous wrote : | I am not sure how this would be implemented internally in jboss-cl, but the implementation should not try to load up the class (as for example ClassLoadeDomain.findLoaderForClass does) since once we get the CtClass it will not be possible to weave it. Ok. I see. So you want it to do the class search and then tell you which module/classloader it belongs to, but not actually load the class. I can certainly add that to our classloader, but not every classloader implementation is going to have that feature. I've already done an implementation like findLoaderForClass which just depends upon using class.getClassLoader() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201377#4201377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201377

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Sub-Profiles ProfileService changes

by emuckenhuber

I've committed a initial prototype on sub-profiles in AS trunk, based on different comments i could gather on this topic. The most important changes are to the ProfileService and Profile spi itself. Where ProfileService got a register and activate method for a profile and the Profile got a list of DependencyItems: | public interface ProfileService | { | // .... | public void registerProfile(Profile profile) | public void activateProfile(ProfileKey key) | public void releaseProfile(ProfileKey key) | public void unregisterProfile(Profile profile) | } | | public interface Profile | { | // .... | Collection<DependencyItem> getDependencies(); | } | The full interfaces can be found here: http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-p... http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-p... One other major change was that i dropped the DeploymentPhase from the profileservice.spi.* interfaces. I think this is not needed anymore, as the relationships and order when profiles are getting installed should be based on the dependency information of the profile. Based on that i've created a simple profile factory which does basically the same as the current profile service, just that there are now 3 active profiles (bootstrap, deployers, $serverName). The profileService itself uses a scoped mc controller to install/uninstall the profiles in the correct order, this is also not really finished, but seems to work for now ;) http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/sy... and the beans.xml: http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/default/... Furthermore i did a simple prototype for xml configuration, based on Adrian's examples in a different thread. So this could for example look like the files in the 2 folders here: http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/resources/parsing... and a simple factory: http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/sy... So basically a sub-profile is just a dependency on a different profile. But the main question for me is - from where should e.g. ejb-runtime know that it depends on ejb-deployers? At the moment i just add some dependencies based on the ordering in the xml, which is not really sophisticated :) There should only be one single test case failure in the profileservice tests, this is because of a changed behavior of the ManagementView, but i would like to discuss ManagementView and DeploymentManager in a different thread later on. Not sure if the clustering tests are using the HASingleton, because i also had to remove the DeploymentPhase there, but it could maybe work - haven't tried that yet. I don't consider the spi as done and there are still some things to do, but i think this is at least a good start for further discussions on that. So any ideas / comments / criticism? :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201376#4201376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201376

17 years, 2 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 January 2009