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

[Design of POJO Server] - Re: jboss-threads brought into jbossas repository...

by david.lloyd＠jboss.com

Here's an interesting problem. I've introduced jboss-threads into the deployers/ folder so that it's available to deployments. However, there's no guarantee that it will be available to other deployers, since they may be deployed before it. What's the best solution? Some kind of ordering directive? A pre-deployer deployers folder? Maybe make the threads deployer part of the bootstrap process somehow? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211254#4211254 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211254

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBAS-6518 - spaces in paths

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Where it is the "vfsLibPath" that is getting cutoff in the wrong place because | the "parentURL" is not escaped properly. The reason the parentURL was not escaped properly was because it was getting serialized from the client side (the testsuite) where I didn't have the version of the VFS that has the JBVFS-89 fixes. Anyway, the code in VFSUtils looks a mess, so I'm going to correct it anyway https://jira.jboss.org/jira/browse/JBVFS-90 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211250#4211250 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211250

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Regression on VirtualFile.toURL()

by scott.stark＠jboss.org

"jason.greene(a)jboss.com" wrote : "jason.greene(a)jboss.com" wrote : | | Which seems to indicate that Ales' consistent use of / on non-leaf urls is the correct approach. | It is within a consistent context like only the vfs using the URLs. The problem is taking a relative path out of the context in which it was originally found, and then simply using new URL(jar, path) where the jar path may or may not be a directory in the spec sense. In reality URL(jarParent, path) should always work as jarParent "should" always be a directory. For ears this always works as they have no manifest classpath notion. For wars its confusing because they can have a manifest classpath as well as nested jars. | | If we built the classpath based on the original context and propagated it with the file with the manifest we would be ok, but this requires non-jdk api usage. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211246#4211246 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211246

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Regression on VirtualFile.toURL()

by jason.greene＠jboss.com

"jason.greene(a)jboss.com" wrote : "scott.stark(a)jboss.org" wrote : "jason.greene(a)jboss.com" wrote : "alesj" wrote : | | | | But wouldn't that make Carlo's impl fail on exploded jar? | | | | | | Yes it would most definitely break on exploded jars. | | | | The issue is that you need to know what the original form of the URL the reference was against. You can't start with a compressed jar with a manifest classpath relative to the jar as a file, and then use the same relative path against the jar as a directory. The jar manifest classpath spec does not deal with this distinction. | | | | If we ever stop unpacking archives such that a jar classpath resolves against an ear which is still packed, we will have the opposite problem of the default relative reference resolution pushing the jar to be outside of the ear. | | So to truly solve this issue, vfs urls would need to be completely logical, and have no distinguishing difference between an exploded directory and a compressed jar. Those really are physical aspects. Which seems to indicate that Ales' consistent use of / on non-leaf urls is the correct approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211245#4211245 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211245

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Regression on VirtualFile.toURL()

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : "jason.greene(a)jboss.com" wrote : "alesj" wrote : | | | But wouldn't that make Carlo's impl fail on exploded jar? | | | | Yes it would most definitely break on exploded jars. | | The issue is that you need to know what the original form of the URL the reference was against. You can't start with a compressed jar with a manifest classpath relative to the jar as a file, and then use the same relative path against the jar as a directory. The jar manifest classpath spec does not deal with this distinction. | | If we ever stop unpacking archives such that a jar classpath resolves against an ear which is still packed, we will have the opposite problem of the default relative reference resolution pushing the jar to be outside of the ear. So to truly solve this issue, vfs urls would need to be completely logical, and have no distinguishing difference between an exploded directory and a compressed jar. Those really are physical aspects. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211244#4211244 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211244

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DeliveryCount & ACKs

by clebert.suconic＠jboss.com

So, in Summary cancelRefs is treating the currentMessage (on the MessageListener) as any other message sent and ACKed on the buffer. Previously it wouldn't touch the counter as it wasn't ACKed. With the current changes is decrementing the counter, as it wasn't ACKed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211241#4211241 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211241

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Regression on VirtualFile.toURL()

by scott.stark＠jboss.org

"jason.greene(a)jboss.com" wrote : "alesj" wrote : | | But wouldn't that make Carlo's impl fail on exploded jar? | | Yes it would most definitely break on exploded jars. The issue is that you need to know what the original form of the URL the reference was against. You can't start with a compressed jar with a manifest classpath relative to the jar as a file, and then use the same relative path against the jar as a directory. The jar manifest classpath spec does not deal with this distinction. If we ever stop unpacking archives such that a jar classpath resolves against an ear which is still packed, we will have the opposite problem of the default relative reference resolution pushing the jar to be outside of the ear. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211238#4211238 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211238

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Regression on VirtualFile.toURL()

by alesj

"alesj" wrote : | The DI::getParent is tricky, as it might not always work - can be null. | It depends on what the VFSContext's root is. | It's then again an impl detail to know that we actually have | a context root that's higher up the hierarchy. | But I guess we can let this one slip as it would be actually weird to have a sub-deployment who wouldn't have a proper parent. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211236#4211236 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211236

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DeliveryCount & ACKs (Repost)

by clebert.suconic＠jboss.com

If we decrement the delivery counter on cancelRefs, we are back to the original issue (The first post on this thread). I have locally done the change, and the issue happened again as I predicted. Another way to fix this would be to make autoCommitAcks = false (as somewhat suggested on JBMESSAGING-1294), and make the JMSWrappers to call Session.commit() when a message is received. I tried that as a quick fix and I could fix the test, however I got a few other issues on the DupsOK. And I also see performance issues with this, as we would make a Commit call on *ever* message received on the AUTO_ACK. Just to make a record about what's the current issue. The parts in bold are the executed parts when the Session is AUTO_ACK. The message is aways acknowledged after listener.onMessage was called on the AUTO_ACK case: | | public void onMessage(final ClientMessage message) | { | | JBossMessage jbm = JBossMessage.createMessage(message, session.getCoreSession()); | | try | { | jbm.doBeforeReceive(); | } | catch (Exception e) | { | log.error("Failed to prepare message for receipt", e); | | return; | } | | if (transactedOrClientAck) | { | try | { | message.acknowledge(); | } | catch (MessagingException e) | { | log.error("Failed to process message", e); | } | } | | try | { | listener.onMessage(jbm); | } | catch (RuntimeException e) | { | //See JMS 1.1 spec, section 4.5.2 | | log.warn("Unhandled exception thrown from onMessage", e); | | if (!transactedOrClientAck) | { | try | { | session.getCoreSession().rollback(); | | session.setRecoverCalled(true); | | } | catch (Exception e2) | { | log.error("Failed to recover session", e2); | } | } | } | | if (!session.isRecoverCalled()) | { | try | { | //We don't want to call this if the consumer was closed from inside onMessage | if (!consumer.isClosed() && !this.transactedOrClientAck) | { | message.acknowledge(); | } | } | catch (MessagingException e) | { | log.error("Failed to process message", e); | } | } | | session.setRecoverCalled(false); | } | | We need to be able to rollback the current message, so the counter are set correctly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211233#4211233 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211233

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBAS-6518 - spaces in paths

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The real issue is why it thinks the jar is a leaf, which I couldn't debug yesterday | because the codebases were majorly out-of-synch. Actually that is not the problem. Now the codebase is no longer out-of-synch I can properly debug it. I added some more TRACE statements and you can see that VFSUtils' manifest processing is not processing the paths properly | 2009-02-18 19:04:15,468 TRACE [org.jboss.deployers.vfs.plugins.structure.jar.JARStructure] (RMI TCP Connection(4)-127.0.0.1) Added context org.jboss.deployers.vfs.spi. | structure.StructureContext@f45574 from spaces.ear | 2009-02-18 19:04:15,468 TRACE [org.jboss.virtual.VFSUtils] (RMI TCP Connection(4)-127.0.0.1) Parsing Class-Path: ./spaces-lib.jar for spaces-ejb.jar parentPath=vfszip: | /home/ejort/jboss-head/testsuite/output/lib/dir with spaces/spaces.ear/ | 2009-02-18 19:04:15,469 TRACE [org.jboss.virtual.VFSUtils] (RMI TCP Connection(4)-127.0.0.1) Unable to find es.ear/./spaces-lib.jar from FileHandler@25523328[path= con | text=file:/home/ejort/jboss-head/testsuite/output/lib/dir%20with%20spaces/ real=file:/home/ejort/jboss-head/testsuite/output/lib/dir%20with%20spaces/] | Where it is the "vfsLibPath" that is getting cutoff in the wrong place because the "parentURL" is not escaped properly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211235#4211235 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211235

17 years, 1 month

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 February 2009