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

[Design of JBoss Profiler] - Re: JBoss Profiler 2

by imavroukakis

Getting this while connecting to the profiler [root@homer jboss-profiler-2.0.CR8]# java -jar jboss-profiler-client.jar getSnapshot 1 2008-01-24 11:36:22,690 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.net.SocketException: end of file at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:575) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) at org.jboss.remoting.Client.invoke(Client.java:518) at org.jboss.profiler.client.cmd.Client.main(Client.java:255) 2008-01-24 11:36:22,696 ERROR [org.jboss.profiler.client.cmd.Client] Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.net.SocketException: end of file java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.net.SocketException: end of file at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:654) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) at org.jboss.remoting.Client.invoke(Client.java:518) at org.jboss.profiler.client.cmd.Client.main(Client.java:255) Caused by: java.net.SocketException: end of file at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:575) ... 5 more View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122988#4122988 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122988

18 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - The first build failed in a non-internet PC but libraries ar

by iamsingfly

------------------------ Enviroment: Jboss-Portal-2.6.2 jboss.4.0.4.GA Apache Ant SVN JDK1.5 ---------------------------- Answer: As we know,when build deploy Jboss-Portal at the first time ï¼it need connet to internet, the PC1 can connect to internet,and down all the libraries in "thirdparty" folder, everything is ok,build success. The problem is, the programm is shared in a non-internet lan according to SVN-server, when deploy-all excuted in other PC, it shows that need connect internet to check the libraries in folder "thirdparty", then build failed and exit... How can we pass the first deploy-all in a non-internet PC like this case? Thanks for your reply! Tanks for anyone can help me. Email: iamsingfly(a)163.com --------------------------------------------------- The key code in the build file is as follows: [PORTAL_HOME]\tools\etc\jbossbuild\tasks.xml : ....  ...  ...  ----------------------------------------------------------- View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122986#4122986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122986

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractVFSDeploymentContext.searchMetaDataLocations too

by alesj

"alesj" wrote : It's a bug I left in FileHandler.createChildHandler. :-( | This goes down to FileSystemContext.createVirtualFileHandler, and it's already fixed in the trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122982#4122982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122982

18 years, 2 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler 2

by imavroukakis

b@lls :) we cannot use jdk1.5 at all with our current codebase, I'm about to try Profiler 2 with 1.6, will let you know what results I get. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122981#4122981 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122981

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractVFSDeploymentContext.searchMetaDataLocations too

by alesj

The IOE shouldn't happen, except for a real IO exception - that's why a warn level. In this case getChild should return null, since the file is not found. It's a bug I left in FileHandler.createChildHandler. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122977#4122977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122977

18 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Deployers conflict

by deruelle_jean

I created the Feature request at http://jira.jboss.org/jira/browse/JBAS-5168. If I may, I have another request but this time regarding the AbstractWebDeployer. Still regarding sip servlets, sip servlets can be converged applications. It means that they can be an HTTP+SIP application and that servlets from both side can play togehter nicely and are tighly integrated by sharing the same context and others objects and as such seen as a web application. They can be packaged as a war or sar. The specification establishes the equivalence of .sar and .war archive formats in the context of SIP Servlet containers so that a .war archive should also be able to contain sip application components and a .sar archive should be able to contain web application components. As such we really need to extend the AbstractWebContainer or for that matter the JbossWeb component to fully leverage the exsiting code allowing web deployment rather then duplicating it and going into maintenance nightmares. But this is not currently possible since the AbstractWebContainer uses hardcoded values to check for .war extension in its init() method and parseMetaData() method. It could be made flexible and allowing for any extensions quite easily (instead of checking lastIndexOf(".war") rather check lastIndexOIf(".") ?). This way we could deploy war or sar leveraging the existing Jboss code. Do you think that would be possible ? If so should I create a Jira Issue too ? Best regards, Jean Deruelle View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122939#4122939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122939

18 years, 2 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler 2

by jesper.pedersen

You'll need a ASM-3.x jar file - the profiler will switch to Javassist before GA. You can use the 1.0.CR4 release together wth AS-4.0: http://labs.jboss.com/jbossprofiler/ Please, note that its a completely different codebase and contains a binary module. See the documentation for further details. Otherwise just try the 2.0.CR8 together with AS-4.0 and report success/failure. Hope this helps ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122898#4122898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122898

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Refactoring ServerPeer

by scott.stark＠jboss.org

Clebert did the 1.4.1.Beta1 release and I have updated trunk to use this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122893#4122893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122893

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - AbstractVFSDeploymentContext.searchMetaDataLocations too ver

by scott.stark＠jboss.org

I'm testing the changes in the current mc trunk and there are a bunch of new warning msgs like: | 21:15:01,478 WARN [WARStructure] Exception while checking if file is a war: java.io.FileNotFoundException: File does not exist: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta4/server/default/deployers/bsh.deployer/WEB-INF | 21:15:01,484 WARN [DeclaredStructure] Exception while looking for META-INF/jboss-structure.xml: java.io.FileNotFoundException: File does not exist: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta4/server/default/deployers/bsh.deployer/META-INF/META-INF | These are innocuous checks for files that don't exist. I have reduced these to debug msgs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122885#4122885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122885

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Scanning for resources, annotations, ...

by alesj

I'm looking at this legacy piece of code | /** | * Scan the current context's classloader to locate any potential sources of Hibernate mapping files. | * | * @throws DeploymentException | */ | private void scanForMappings() throws DeploymentException | { | // Won't this cause problems if start() is called from say the console? | // a way around is to locate our DeploymentInfo and grab its ucl attribute | // for use here. | URL[] urls; | ClassLoader cl = Thread.currentThread().getContextClassLoader(); | if ( cl instanceof RepositoryClassLoader ) | { | urls = ( ( RepositoryClassLoader ) cl ).getClasspath(); | } | else if ( cl instanceof URLClassLoader ) | { | urls = ( ( URLClassLoader ) cl ).getURLs(); | } | else | { | throw new DeploymentException( "Unable to determine urls from classloader [" + cl + "]" ); | } | | // Search the urls for each of the classpath entries for any containing | // hibernate mapping files | VirtualFileVisitor visitor = new HibernateMappingVisitor(classpathUrls); | // visit har url if set | if (harUrl != null) | visitURL(harUrl, visitor); | // visit CL urls | for ( int j = 0; j < urls.length; j++ ) | { | final URL entry = urls[j]; | visitURL(entry, visitor); | } | log.trace("Found mappings: " + classpathUrls); | } | and I think it's time for us to introduce a uniform way of plugging into deployers to help us with the scanning + caching the results for later usage, before things get out of hand, e.g. dozen new lines of scanning code in every project. :-) I was able to get around the URLCL issue in Seam, since Pete re-organized the code with more info. But here I fail to see how to get this thing working w/o breaking existing (user) configuration. OK, I guess this bean can be made deprecated, but I think it can be a lesson learned - showing how to transform URLCL aware code to do the same with the new VFSCL. Until our uniform way kicks in, of course. ;-) Not to mention that this code is broken from begining - see the comment. ;-) And since Adrian just addressed the CL usage to be handled more stricktly, it's another use case example to cover. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122853#4122853 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122853

18 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 2008