Hello,Actually, JOnAS <http://jonas.ow2.org>is the best way to easily conciliate OSGi, and J2EE worlds.
It also offers many J2EE an OSGi technical services that could help you.
Le 3/2/2010 1:49 PM, Miguel a écrit :
start stop processes can be a method with an id argument... threads can be stored in a list, hash or similar ... It should be better than a bundle for each process ... in my opinion it is a little weird what you comment ..MiguelOn Tue, Mar 2, 2010 at 1:15 PM, Abhishek kapoor <[email protected] <mailto:[email protected]>> wrote:Hi Chris, Thread pooling can sort some of the issues but we need the facility to start and stop the process independently. Also it will be great to reload the process again with some change and not to mention versioning between bundles with changes etc.. Thanks San Thanks On Tue, Mar 2, 2010 at 5:13 PM, Christopher Armstrong <[email protected] <mailto:[email protected]>> wrote: Why not move the code into the same process, and run each as a separate thread? There are plenty of thread pooling technologies about. Bundles don't run in OSGi like processes, they have a "start" and "stop" method, but if they are to run an active task, they will need to start up a thread for themselves anyway (which is effectively what happens when you create a process in the operating system - it starts your process with one thread ( the main thread) and executes your code on it until the thread exits). Cheers Chris On 02/03/2010, at 22:20 PM, Abhishek kapoor wrote:Hi Chris, Thanks for your time and comments. What I meant by single process per JVM is. At the moment we use, lets say process A which fetch data from DB and process accordingly. We initiate a JVM for the respective process [that is a instance of JVM is booted for that process]. We do similar thing for atleast 30 process, that create 30 instance for JVM, so in-order to avoid one instance of JVM per process, i thought why not incorporate in osgi framework by creating bundle per process instead new JVM instance. Application is back middle system so i don't understand the need J2EE stack for it. Hope this time I am much clear. Thanks San On Tue, Mar 2, 2010 at 4:15 PM, Christopher Armstrong <[email protected] <mailto:[email protected]>> wrote: Hi I don't know what you are looking for from this list, but you are unlikely to find it. At a quick glance, the requirements you mention below could be easily fulfilled by a enterprise J2EE stack or written into a lightweight container framework like Spring. Why do you need OSGi? You are also unclear on what you mean by "a separate process per JVM". All Java applications, including a running OSGi framework, use one process per JVM instance. If you mean a single process per requirement, that still is not unusual - using something like JMS for integration would fit well with such an architecture. Cheers Chris On 02/03/2010, at 20:59 PM, Abhishek kapoor wrote:Dear Member, Thanks for reading this email. I need your kind help regarding convincing my manager to adopt OSGI in our future development. Below is the current application architecture We are telecom company and at the moment we use separate JVM per process for our middleware for Order management system. Below are the general overview of the all the process 1) Fetch data [ JDBC]from DB do some processing insert the processed data into DB 2) One of the process send data outside our system through webservice 3) One of the process receive data from outside and pushes into DB so that our internal process can work accordingly 4) Each process polls the data at given specified time for it processing 5) Each process also use extensive logging Since it is a legacy system I do understand the above mentioned process flow is horrible. I guess in past developers decided single process per JVM to achieve modularity. Any Help is appreciated Any case history related to telecom to convince my manager will highly beneficial Thanks San _______________________________________________ OSGi Developer Mail List [email protected] <mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev-------- Christopher Armstrong [email protected] <mailto:[email protected]> _______________________________________________ OSGi Developer Mail List [email protected] <mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] <mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev-------- Christopher Armstrong [email protected] <mailto:[email protected]> _______________________________________________ OSGi Developer Mail List [email protected] <mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] <mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
-- ZENG EYINDANGA Landry Stephane, Ingénieur Développement, Bull Service, Section R&D, équipe Java Entreprise Middleware, Echirolles, Tél:04 76 29 72 07
<<attachment: LANDRY-STEPHANE_ZENG-EYINDANGA.vcf>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
