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

[Design the new POJO MicroContainer] - Re: Those terrible error messages

by david.lloyd＠jboss.com

Doing some testing in JBAS trunk, I triggered the new error message: | Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): | | DEPLOYMENTS MISSING DEPENDENCIES: | Deployment "TestTCPServer" is missing the following dependencies: | Dependency "XnioProvider" (should be in state "Instantiated", but is actually in state "Described") | Deployment "XnioProvider" is missing the following dependencies: | Dependency "XnioSelectorThreadFactory" (should be in state "Instantiated", but is actually in state "Described") | Deployment "XnioSelectorThreadFactory" is missing the following dependencies: | Dependency "XnioSelectorThreadGroup" (should be in state "Instantiated", but is actually in state "Described") | Dependency "XnioThreadInterruptHandler" (should be in state "Instantiated", but is actually in state "** NOT FOUND Depends on 'XnioThreadInterruptHandler' **") | Deployment "XnioSelectorThreadGroup" is missing the following dependencies: | Dependency "xnio" (should be in state "Instantiated", but is actually in state "** NOT FOUND Depends on 'xnio' **") | | DEPLOYMENTS IN ERROR: | Deployment "xnio" is in error due to the following reason(s): ** NOT FOUND Depends on 'xnio' ** | Deployment "XnioThreadInterruptHandler" is in error due to the following reason(s): ** NOT FOUND Depends on 'XnioThreadInterruptHandler' ** | It looks pretty nice I think. One thing that doesn't quite make sense though is the "** NOT FOUND" part... it says "Depends on XXX" but it's listing its own bean there. If I get a minute, I'll try to find where this is coming from and turn it into a nicer "not found" message... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211300#4211300 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211300

17 years, 1 month

1
0
0 / 0

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

by jason.greene＠jboss.com

"wolfc" wrote : I'll implement the second construct. It leads to regression when deploying output directories in unit tests, but then again relative path is underspecified in those cases. | The spec could use a formal definition of 'a directory containing an exploded jar file'. Any reason to use it over the first construct? It should be more reliable. Does the above regression occur with it as well? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211289#4211289 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211289

17 years, 1 month

1
0
0 / 0

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

by wolfc

I'll implement the second construct. It leads to regression when deploying output directories in unit tests, but then again relative path is underspecified in those cases. The spec could use a formal definition of 'a directory containing an exploded jar file'. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211288#4211288 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211288

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Stable deployment API for tools

by jason.greene＠jboss.com

The tools team is concerned that the profile service is too much of a moving target, and that they need a stable API & protocol that is BC across minor releases. Since their usage is limited to basic deployment (they actually preferred using JMX), should we consider a simple wrapper service API for this use-case? It would then be much easier to guarantee backwards compatibility. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211287#4211287 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211287

17 years, 1 month

1
0
0 / 0

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

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : Deployers don't need to manage threads they just process metadata. Ah. I was thinking from the perspective of the forthcoming XNIO deployer, which I was thinking would set up the thread stuff and the base provider as well as installing the actual deployer; though looking at it this way, those pieces probably should be considered a deployment and go into an "xnio-jboss-beans.xml" in deploy, which makes the whole issue disappear... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211275#4211275 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211275

17 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | So we can do it one way or the other in the VFS, the / on the end is more logical | It still looks weird though to see a packed jar url followed by a / but it is logical since it does contain children. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211274#4211274 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211274

17 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"jason.greene(a)jboss.com" wrote : | 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. I'm not sure it solves the real problem, but it would certainly provide a consistent basis on which it could be solved. The problem as currently described by Ales is that adding a "/" helps webapps/libraries that naturally expect their directories to be unpacked (most webservers do it) so the directory urls will always end with / Carlo's code is expecting his persistent units to be packed in jars. In practice, both are wrong and both should take more care when processing urls. So we can do it one way or the other in the VFS, the / on the end is more logical but its bound to break somebody else's code besides jpa (and vice versa). The fix to Carlo's code is one of: 1) Use the VFS (which will work however Ales changes the URLs) | -URL url = di.getFile("").toURL(); | -return new URL(url, jar); | + VirtualFile di = di.getFile(""); | + return di.getParent().getChild(jar).toURL(); // Obviously needs to check for null | 2) Handle the URLs correctly | URL url = di.getFile("").toURL(); | +if (url.getPath().endsWith('/') | + return new URL(url, "../" + jar); | return new URL(url, jar); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211271#4211271 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211271

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process definition as a resource

by heiko.braun＠jboss.com

nobody will rename the classes. but you'd need to rename the deployment artifact (i.e. myProcess_v2.par). Otherwise you'd force redeployment of an existing deployment artifact. But the then it works like Bernd says, the scoping is guaranteed by the classloading/deployer framework. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211266#4211266 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211266

17 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : 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? Deployers don't need to manage threads they just process metadata. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211259#4211259 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211259

17 years, 1 month

1
0
0 / 0

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

by david.lloyd＠jboss.com

To expand a little - I would rely on the dependency mechanism but since there's a parser involved, it seems that it won't even parse a jboss-beans.xml which contains a "threads" tag, or a deployment which includes a jboss-threads.xml, even if there is a directive to indicate that it depends on the threads deployer bean... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211257#4211257 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211257

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