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

[Design the new POJO MicroContainer] - Re: cts config startup issue with current vfs trunk

by scott.stark＠jboss.org

"alesj" wrote : "scott.stark(a)jboss.org" wrote : | | The sun jar protocol handler should not be getting called as only vfs* urls should be in use. | This is not the case, see that JarContextFactory also takes all jar* urls, and FileSystemContextFactory takes file. | We either need to supply our own jar protocol handler, or change the way JarContextFactory deals with jars. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133383#4133383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133383

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: cts config startup issue with current vfs trunk

by scott.stark＠jboss.org

Jar urls are being created for the SynthenticDirEntryHandler types of empty directories in jars. Eventually a nested jar:jar url is being created for a jar in derbyTesting.jar: jar:jar:file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/derbyTesting.jar!/org/apache/derbyTesting/functionTests/testData/v1/j1v1.jar!/META-INF/ that jar should not be in the lib dir, but we also should handling this correctly. I also don't think we should be relying on the jdk jar: url handler to deal with the jar contents. It internally relies on JarFile which is not serializable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133382#4133382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133382

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: cts config startup issue with current vfs trunk

by alesj

"scott.stark(a)jboss.org" wrote : | The sun jar protocol handler should not be getting called as only vfs* urls should be in use. This is not the case, see that JarContextFactory also takes all jar* urls, and FileSystemContextFactory takes file. The weird thing is that this url looks like it's broken from the beginning, since if you follow it from the start -> in JarContextFactory.getVFS, it is never modified, going all the way toAbstractURLHandler.initCacheLastModified. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133381#4133381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133381

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Careful with default serialization, JBVFS-17

by alesj

Serialization for nested jars is broken anyway. See the problem that I somehow hinted about in AbstractJarHandler.handleJarFile. The thing is that when you do | JarURLConnection jconn = (JarURLConnection) conn; | jar = jconn.getJarFile(); | on an url that points to nested jar, you're gonna get only the first non-nested jar. And doing jar.getEntry(current.getName()) on it, will return null, or the wrong entry (in case the names are accidentally equal). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133380#4133380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133380

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - cts config startup issue with current vfs trunk

by scott.stark＠jboss.org

I'm trying to test a fix for JBVFS-17, and I'm seeing the startup problem Dimitris had mentioned seeing earlier, but I had not: | Caused by: java.lang.Error: Error visiting JarHandler(a)1535839050[path=derbyTesting.jar context=file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/ real=file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/derbyTesting.jar] | ... | Caused by: java.net.MalformedURLException: no !/ in spec | at java.net.URL.<init>(URL.java:601) | at java.net.URL.<init>(URL.java:464) | at java.net.URL.<init>(URL.java:413) | at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:161) | at java.net.JarURLConnection.<init>(JarURLConnection.java:144) | at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:61) | at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24) | at java.net.URL.openConnection(URL.java:943) | at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:72) | ... 54 more | 14:28:35,687 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): | | *** CONTEXTS IN ERROR: Name -> Error | | vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/conf/jboss-service.xml -> java.net.MalformedURLException: no !/ in spec | The sun jar protocol handler should not be getting called as only vfs* urls should be in use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133379#4133379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133379

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Careful with default serialization, JBVFS-17

by scott.stark＠jboss.org

The serialization of the NestedJarFromStream is incorrect. Its using default serialization of these fields: private transient ZipInputStream zis; private URL jarURL; private URL entryURL; private long lastModified; private long size; private AtomicBoolean inited = new AtomicBoolean(false); The problem is that the inited flag should not be serialized as this implies its parents fields: private transient List entries; private transient Map<String, VirtualFileHandler> entryMap; have been initialized. They will not be after deserialization of NestedJarFromStream as it lazily does initialization. We need to be careful when adding fields to a class that is using the default java serialization contract. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133376#4133376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133376

16 years, 10 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by alesj

"johnbailey" wrote : The other issue I had was getting the MainDeployerImpl and DeployersImpl created at Test bootstrap without creating a project dependency from osgi-int to deployers-impl. | | Referencing deployers-impl in a test should be ok, correct? It is referenced in the pom already. | Add that dependency just for the test scope. e.g. | <dependency> | <groupId>org.jboss.microcontainer</groupId> | <artifactId>jboss-deployers-impl</artifactId> | <scope>test</scope> | </dependency> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133374#4133374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133374

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by alesj

"johnbailey" wrote : I will see if there is anything we can use. Would we include these directly, with modifications to bootstrap the MC, or "create" similar tests? I would use them directly. It would be specially good if we were able to pull them out from some maven2 repo. And then, like you suggested, just add small bootstrap/integration framework around them for the MC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133373#4133373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133373

16 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by snasto

I get the same error when shutting down jboss4.3 "org.jboss.jms.wireformat.JMSWireFormat is not registered" Is any fix for it available? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133356#4133356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133356

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by johnbailey

"adrian(a)jboss.org" wrote : | I'd be happier porting the relevant eclipse or apache felix tests to our framework | before trying the TCK since those can be distributed under their relevant OS licenses. "alesj" wrote : | John? :-) I will take a look at the Felix test. I have read through the majority of the Felix core, but not much on the test side of things. I will see if there is anything we can use. Would we include these directly, with modifications to bootstrap the MC, or "create" similar tests? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133355#4133355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133355

16 years, 10 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 February 2008