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

[Design of OSGi Integration] - Re: OSGi integration

by alesj

"vickyk" wrote : | So when the osgi bundles would be deployed in the Jboss the Jboss Deployment architecture will not create the UCL but the osgi style CL for these deployment artifacts(bundles). | I already does that. ;-) It's just that currently it's import all / export all. Unless you have jboss-classloading.xml present, with more exact requirements / capabilities. As you can see, I already wrote deployers that do the following transformations: manifest.mf (A) --> osgi metadata (B) --> cl metadata (C) Every step of this transformations needs further testing. (A) --> (B): - is javacc parsing of manifest.mf bullet proof - is osgi metadata feature complete (B) --> (C): - do we port all of osgi features to cl metadata - check osgi/cl corner cases ... I've used some of this stuff already here (for C1 demo): - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179723#4179723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179723

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Classloader-Registry in AS/ESB allows one central jbpm i

by kukeltje

"camunda" wrote : | Versioning is applied to applications and services, normally correspond to one EAR (with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service). There are two versioning schemes: | | 1.) Major Versions: Bigger changes. These may be not compatible. New major versions may be run in parallel to older services. | | 2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New Minor versions replace the existing service. | Ok, clear. Would be my take to. "camunda" wrote : | The EAR includes the version in its name, so all beans and stuff include the version in the JNDI-Name. | You do this manually (deploy time), manually (design time) or is this some automagic JBoss AS feature? "camunda" wrote : | jBPM-processes are included in this EAR. New major versions will create new processdefinition names (basically the version is added to the process name, e.g. "websale_3"). | Again, do you do this deploy time or designtime? "camunda" wrote : | "Normal" jbpm versioning is only applied on patch level. | Ok, makes me even more curious how you achieve this. The high-level take on it is clear, now the devil^W details ;-) "camunda" wrote : | anonymous wrote : It is a more generic problem than just jBPM. | | Exactly, normally you have to take care of versioning for a lot of artefacts, so I think this solution makes sense... And I like having bytecode and classpath stuff in EAR files more than in the jBPM database... | It does make sense, I miss one thing though but I'll talk about that in the end. "camunda" wrote : | | anonymous wrote : So maybe we could come up with something together with the seam guys | | Yeah, maybe. But I think it is not only seam, but much more. Especially if you look into the direction of the ESB with whatever services connected to it. This direction (to the backend) is also very interessting. You are right, but currently I am (was) focussing on the web side of things. How do you run multiple major versions next to eachother? Suppose I have App A-v1 (version 1) on http://myhost/AppA. That is easy to run. But now comes AppA-v2, an incompatible major release. Running this on http://myhost/AppA. is not possible since we already have AppA-v1 there, so something more advanced needs to take place. One thing I came upo with (and I do not know all the disadvantages yet, or alternatives, so please shoot) is to have an AppA 'wrapper' which contains things like showing tasklist (since our customers do not want to use to different 'apps' because there are newer versions), basic navigation etc which is a war by itself running on url http://myhost/AppA. The 'versioned' parts are in separate deployable artifacts (war or ear) running on urls like http://myhost/AppA-v1 or http://myhost/AppA-v2 of which the wrapper has knowledge via some defined schema so it can make a link directly to a task. But there probably needs to be some kind of 'TaskHandlingPageUrlService' to retrieve that. I'll not go into it any further now and just let you guys shoot... But I do think there needs to be some more generic mechanism for all this Gourvernance stuff... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179718#4179718 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179718

16 years, 2 months

1
0
0 / 0

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

by mstruk

If the archive isn't deleted before the new version is copied over, I'd try that using VirtualFile.delete(). I was dealing with a similar issue: - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138343 - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179716#4179716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179716

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: perfSender/perfListener is acting weird

by timfox

I fixed an issue in QueueImpl that might be causing this, but I can't commit yet due to other changes. If you want to apply the fix yourself locally, add the following synchronized block in DeliverRunner in QueueImpl.java | | private class DeliverRunner implements Runnable | { | public void run() | { | // Must be set to false *before* executing to avoid race | waitingToDeliver.set(false); | | //must synchronize | synchronized (QueueImpl.this) | { | deliver(); | } | } | } | | Without the synchronize block messages can get lost and get delivered out of order View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179715#4179715 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179715

16 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi integration

by vickyk

"alesj" wrote : | The jboss-cl project is able to do OSGi kind of classloading. | All you need to provide is the right CLMetaData. | | But to make sure this is _really_ the case, | we need to engage the OSGi specific tests on top of jboss-cl. | Okay here seems the osgi classloading project http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl So when the osgi bundles would be deployed in the Jboss the Jboss Deployment architecture will not create the UCL but the osgi style CL for these deployment artifacts(bundles). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179713#4179713 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179713

16 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: HAJNDI access of NamingContext.localServer

by bstansberry＠jboss.com

Sounds good. anonymous wrote : For the related TODO in the HAJNDI code we really should be injecting the Naming instance. When I integrate the next jnpserver version I will be switching the naming service configuration to be an mc -beans.xml deployment. When you change the naming service config to -beans.xml, do you intend to add the injection into DetachedHANamingService, or shall I add a JIRA to handle that myself? I'll also be converting the hajndi-service.xml back to a -beans.xml for GA, so it's convenient enough for me to add the injection when I do that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179703#4179703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179703

16 years, 2 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 October 2008