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

[Design of POJO Server] - Re: Hotdeployment is still broken

by adrian＠jboss.org

There are actually two quick fixes which solve the initial problems described above. 1) Copy some of the "sanity" rules into the SerializableDeploymentRepository such as not recursing into directories that have a dot in the name (although even for that rule there is a FIXME in the HDScanner :-). This doesn't solve the fundamental issue which is that profile implementations should be definable per sub-profile. The repository should not be interfering with the initial definition or assuming anything about it, let alone being that definition. 2) Include the MetaDataAware handling in the SerializableDeploymentRepository so we know when deployment descriptors (anything in the metadata-locations) get modified. The other problems are much too fundamental for quick fixes. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191885#4191885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191885

15 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1396 MockServer must report startup / shutdown

by ALRubinger

I'm actually surprised this works for you. After launching the remote process, we need to wait a bit until it opens the command socket. From my MockServerController.startServer(): createRemoteProcess(processArgs); | | /* | * Wait a max of 5 seconds for the remote process to start | */ | long start = System.currentTimeMillis(); | int timeoutIntervalSeconds = 5; | long timeout = timeoutIntervalSeconds * 1000 + start; | while (true) | { | try | { | // Start the server | sendStartRequestToServer(); | } | // Couldn't start server | catch (CannotConnectException cce) | { | // If we haven't yet timed out | long current = System.currentTimeMillis(); | if (current < timeout) | { | // Swallow exception and try again | logger.trace("Can't connect to server @ " + current + ", trying until " + timeout); | Thread.sleep(100); | continue; | } | | // Throw the exception, timeout's past | throw cce; | } | } Even after that, I'm getting CNFEs when the command to start the server is received: 15:26:01,003 ERROR [AbstractKernelController] Error installing to PreInstall: name=org.jboss.ejb3.JndiRegistrar.Session.SLSBJndiRegistrar state=Not Installed | java.lang.ClassNotFoundException: org.jboss.ejb3.proxy.jndiregistrar.JndiStatelessSessionRegistrar ...which is odd, I can see that the CP is getting set correctly to the remote process command: /opt/sun/java/jdk1.5.0_15/bin/java -cp "/home/alrubinger/business/jboss/wc/jbossas/projects/ejb3/trunk/proxy/target/classes:...[etc]" -ea org.jboss.ejb3.test.proxy.remoteaccess.MockServer org.jboss.ejb3.test.proxy.remoteaccess.unit.RemoteAccessTestCase localhost 12345 Running this directly from the shell works just fine. I'll have to look into this more later, probably after this week. Some other misc impressions to be elaborated upon later: * MockServer isn't Thread-safe and there's some inconsistent synchronization when accessing its state, etc. * I neglected to provide facility for parent CLs in my Hack CLs that do the jndi.properties replacements. * Let's use Generics: Map configParams = new HashMap(); | configParams.put("timeout", String.valueOf(TIMEOUT)); * Make an SPI (expose publically) the value of the "timeout" String for the config params * Always reset TCL to the original in a "finally" block. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191882#4191882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191882

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Hotdeployment is still broken

by adrian＠jboss.org

Ok, Sacha/Scott asked me to look at this (well actually he asked me to look at something else but this is close enough ;-) This hasn't moved on much since I first raised this issue: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064180#4064180 and as Charles points out on the JIRA, the touch of deployment descriptors is broken again http://www.jboss.com/index.html?module=bb&op=viewtopic&t=145508 The basic issue here is that we now have three scanning mechanisms (one of which isn't currently getting used). There is 1) the HDScanner which has some sane rules and a decent abstraction but it is only used during the initial scan at bootstrap time 2) a MetaDataAwareProfile that knows where deployment descriptors live 3) a SerializableDeploymentRepository that assumes incorrectly that a profile is made of local directories Neither (2) or (3) are aware of the "sane" rules that the initial HDScanner used when determining what is a deployment. The SerializableDeploymentRepository also doesn't seem to understand that there should be any number of (sub-)profiles and that they could be activated "on the fly": http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136492 It doesn't seem to understand (sub-)profiles at all? There is an APPLICATION_TRANSIENT phase in there but it doesn't look to be complete or have a notion of whether a (sub-)profile is currently active when looking for modifications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191881#4191881 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191881

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5953; jar override issue

by alesj

"scott.stark(a)jboss.org" wrote : It should be the deployment that contains the metadata to setup the vfs behavior as needed, not the deployer call. Yes, this is probably the right fix. I'll add the following two checks in VFSDeploymentFactory. 1) check for vfs.properties in top deployment's root META-INF 2) check for VFSMetaData in predetermined attachments Eventually creating the root accordingly to VFSMetaData. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191875#4191875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191875

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5953; jar override issue

by alesj

"dimitris(a)jboss.org" wrote : | The client only cares about deploying a URL. He doesn't care how this should be done or what is VFS and especially not what VFS options would be needed to workaround a particular problem. | I agree on VFS and impl details, but I disagree on what the client cares about. e.g. we can easily say we don't support super quick re-deploys. In this case the cause is reaper, who's performance benefits out-weigh user's simplicity to do quick re-deploy. The only cost is to know what option to set. Before we didn't have such options, now we do. Is this a good this? More options is always good. ;-) Perhaps we could make them more human nameable. e.g noReaper --> quickRedeploy "dimitris(a)jboss.org" wrote : | If we need to workaround the problem for this particular testcase, that's easy, just introduce a small delay and a note pointing to a JIRA with future work on this. | I don't see this impl change as workaround. Looking at it better it was expected. We had similar issue on PS's handling of deployments. We eventually introduced VFS:delete, which knows how to halt current reaper, hence enabling file for deletion. This test case just shows what user can do if it has a deployment which is gonna be redeployed in less than reaper's work time unit. "dimitris(a)jboss.org" wrote : | Extending the MainDeployer api with implentation details doesn't offer any real value, it just complicates things. | The way it's currently done yes, if we put generic Map, then no. It's not the nicest api, but it dos the job. e.g. programmatic deployment But see Scott's next post for better suggestion. "dimitris(a)jboss.org" wrote : | And BTW, I think all VFS options should be visible in bootstrap/vfs.xml with the user able to override them in the command line, or by modifying the file. Yes. I'll add a JIRA for you to do this. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191872#4191872 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191872

15 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging code review

by timfox

One other point: 11) Need to sync paging on non transactional persistent page, if corresponding config property is set View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191866#4191866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191866

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by sacha.labourey＠jboss.com

so let's get rid of concurrent.jar in 6.x View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191861#4191861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191861

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 2) Include the jbossmq-client.jar from whatever version you are running against | when it is pre 5.0.x in the classpath | | (2) Is what you would do for any other remote jms and it is also what | users will have to do if they want JBoss5 to use an older JBoss running jbossmq | as their JMS server. | But this isn't testing very much in terms of compatiblity since you are running with the same classes on both sides. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191860#4191860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191860

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by adrian＠jboss.org

"dimitris(a)jboss.org" wrote : | BTW, now different issues show up, on of which is the missing jbossMQ classes, now that it was removed from trunk :-) | Which way around is this test? I guess this is the 5.0.x testsuite (i.e. client side) running against a 4.2.x server? The other way around wouldn't work either. 4.2.x doesn't include the jboss messaging jars. :-) There's two likely solutions as far as I can see. 1) Disable the test for 5.0.x talking to older versions (its still needed for future tests of JBoss Messaging compatiblity) 2) Include the jbossmq-client.jar from whatever version you are running against when it is pre 5.0.x in the classpath (2) Is what you would do for any other remote jms and it is also what users will have to do if they want JBoss5 to use an older JBoss running jbossmq as their JMS server. Or a there's a third option which is to include a binary version of jbossmq-client.jar from 4.2.x in the shared lib directory of JBoss5 to make things easier for users (although its not exactly rocket for them to copy it across themselves. :-) The downside of the third option is that it introduces a permenant dependency on concurrent.jar (jbossmq still uses it) which I think we'd like to get rid of at some point soon. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191859#4191859 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191859

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by dimitris＠jboss.org

The naming issue looks resolved, so I'll create a 5.0.0.SP1 for that. BTW, now different issues show up, on of which is the missing jbossMQ classes, now that it was removed from trunk :-) anonymous wrote : at org.jboss.test.jbossmq.test.JBossMQUnitTest.testQueueMessageOrder(JBossMQUnitTest.java:181) | at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestProxy.run(MatrixTestContainer.java:185) | at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestSuiteProxy.run(MatrixTestContainer.java:85) | Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: | java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled) | at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162) | at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:713) | ... 23 more | Caused by: java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled) | at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) | at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) | at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) | at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191848#4191848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191848

15 years, 10 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 November 2008