Hi guys,
Not a real design question, but certainly not a user question (imo). I just checked out the esb source and want to digg into it a little. I normally develop using Eclipse and was wondering if there is any guidelines of setting this up. I can do it all manually (creating new eclipse projects of the parts like core, console etc individually based on the ant build scripts in those subdirs) so they become individual eclipse projects.
Or is there any better way? If not, no problem, but then I know I just have to do some work....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020658#4020658
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020658
Added to the jira:
Not only hot, but
- Scheduled: e.g. 'deploy now' become active at 23:00 (or 11pm ;-) ), or mark a service as becomming unavailable a 3 weeks from now
- Versioned: Service A version 1 uses Service B version 2, Service B gets a new version, needed for other things, but Service A should still be able to use Service B version 2 for as long as needed.
If I think of more examples/requirements, I'll add them here.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020623#4020623
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020623
"scott.stark(a)jboss.org" wrote : Are you traversing all contexts across all kernels for a given state?
|
I'm doing a simple current --> parent chain context lookup.
The problem is when a CL bean is defined in some scope, it is part of the ScopedController after PreInstall state. But the CL bean dependant beans are still in the 'Not installed' state, since they need CL for MetaData, so they are still having a bootstrap Controller assigned to them - which doesn't know about context's in his child Controllers == ScopedControllers.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020541#4020541
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020541
apache-tomcat is a dependency of Remoting. Remoting can't do HTTP unless those jars are present. Messaging, as a Remoting dependent, shouldn't be in the position to decide what apache-tomcat version Remoting uses. From our perspective, we don't care, and we don't want to be forced to care.
All we care about is that our tests pass with the specific Remoting version listed in our dependency metadata.
So, having to list apache-tomcat among our dependencies is wrong.
If Remoting declares itself compatible on apache-tomcat 5.5.15, and this breaks compatibility with jbossweb 2.0.0, then jbossweb and Remoting teams need to work this out and qualify a apache-tomcat that is acceptable for both parties.
Also, they need to do this in such a way that doesn't require uncomment stuff in configuration-info.xml and leave Tim and I wondering for hours why is that our testsuite fails.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020400#4020400
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020400