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

[Design the new POJO MicroContainer] - Re: VFS and directory handling

by scott.stark＠jboss.org

The only more generic way that would allow for compatibility modes would be to rely on the content-type rather than the url. However, no one uses that. They look at the url scheme or the file suffix and make assumptions about what the url points to, or its InputStream. There are standard content-type descriptions for a zip input stream, but I don't know about a java.io.File object. Maybe there is an application/x-java-object-java.io.File type defined somewhere. A nested jar should simply be seen as a JarInputStream. "http://java.sun.com/javaee/5/docs/api/javax/persistence/spi/PersistenceUn..." wrote : | getJarFileUrls | | List getJarFileUrls() | | Returns a list of URLs for the jar files or exploded jar file directories that the persistence provider must examine for managed classes of the persistence unit. Each URL corresponds to a named element in the persistence.xml file. A URL will either be a file: URL referring to a jar file or referring to a directory that contains an exploded jar file, or some other URL from which an InputStream in jar format can be obtained. | | Returns: | a list of URL objects referring to jar files or directories. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154262#4154262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154262

15 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS and directory handling

by alesj

"wolfc" wrote : It's PersistenceUnitInfo that has the responsibility to be spec compliant, but it's VFS that has to provide the facilities to enable it to do so. What does JPA expect to get in the case of nested jar? It's neither file or jar. OK, not file is obvious. >From the spec: anonymous wrote : | .. other URL from which an InputStream in jar format can be obtained. | In our case this could be it. If they then did this | ZipInputStream zis; | if (is instanceof ZipInputStream) | zis = (ZipInputStream)is; | else | zis = new ZipInputStream(is); | But this would mean that the URL returned had to be VFS based - so that VFSURLConnection would kick in, pointing to nested jar. Which then returns itself as ZipInputStream. But there is another catch. Imagine you have that jar in exploded form. How do you then know weatehr it's a nested jar or just plain dir? Since for plain dir this does the trick: | String urlString = url.toExternalForm(); | if (urlString.startsWith("vfs")) | url = new URL(urlString.substring(3)); | And we're back to Scott's description: "scott.stark(a)jboss.org" wrote : | This is the same situation that exists without the vfs for exploded vs packed jars. The only difference without the vfs is that the url prefix is probably jar: for packed, file: for exploded. There is no generic solution I can see | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154256#4154256 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154256

15 years, 12 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: sub-tasks of JBAS-5384

by thomas.diesler＠jboss.com

Well, you made an inval change to jbossxb that breaks stuff and shows in the jbossws test suite. There is a two step process to reproduce the failure and an infinitly more complex process to send artifacs forth and back. Moreover the failure is probably a duplicate of http://jira.jboss.com/jira/browse/JBWS-720 which you have fixed in the past. Now it is broken again. The artifacts you ask for are available here http://fisheye.jboss.com/browse/JBossWS/stack/native/trunk/modules/testsu... and the related resources dir - this of course I don't need to tell you ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154251#4154251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154251

15 years, 12 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by jesper.pedersen

Yeah, sorry about that - I meant it the other way around as the discussion described it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154250#4154250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154250

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBossSessionBeanMetadataCreator a la EjbJar30Creator

by alex.loubyansky＠jboss.com

It's not used currently, actually. I am writing the tests and fixing the override logic where needed. Then there will have to be a refactoring to replace EjbJar30Creator. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154247#4154247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154247

15 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS and directory handling

by wolfc

It's PersistenceUnitInfo that has the responsibility to be spec compliant, but it's VFS that has to provide the facilities to enable it to do so. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154246#4154246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154246

15 years, 12 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by adrian＠jboss.org

"jesper.pedersen" wrote : | Feel free to add examples to the JBossTS documentation on how to inject the registry into other beans using the MC or JMX ;) | You don't inject the registry. Instead your object is injected into the registry because it implements the interface. See discussion above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154245#4154245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154245

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBossSessionBeanMetadataCreator a la EjbJar30Creator

by alex.loubyansky＠jboss.com

I committed it yesterday https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java... It should replace EjbJar30Creator when complete. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154244#4154244 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154244

15 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by vickyk

"alesj" wrote : | OK, good point - backcompatibility. | I'll put that method back. And here I have the passing test ;) test: | [delete] Deleting: /tmp/test.log | [junit] Running org.jboss.test.jcaprops.test.GoodrarUnitTestCase | [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4.101 sec | [junit] Running org.jboss.test.jcaprops.test.JBossRaXmlOverrideUnitTestCase | [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.113 sec | [junit] Running org.jboss.test.jcaprops.test.UpperGoodrarUnitTestCase | [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.872 sec | | BUILD SUCCESSFUL Let me run all the jca tests now . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154240#4154240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154240

15 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by alesj

"vickyk" wrote : anonymous wrote : Why is EJB deployer using that? :-) | This might be helpful to findout what is using the parse method which you have removed | | Caused by: java.lang.NoSuchMethodError: org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(Lorg/jboss/virtual/VirtualFile;)Ljava/lang/Object; | | at org.jboss.deployment.JBossEjbParsingDeployer.getStandardMetaData(JBossEjbParsingDeployer.java:211) | | at org.jboss.deployment.JBossEjbParsingDeployer.createMetaData(JBossEjbParsingDeployer.java:112) | | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:236) | | at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174) | | ... 64 more | | | OK, good point - backcompatibility. I'll put that method back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154233#4154233 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154233

15 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2008