در مورد jndi

[bahareh12]

با سلام اگر کسی JNDIAPI استاندارد جاوا را میشناسه لطفا کمک کنه چون تو مرحله IMPLEMENT پروژه ام خیلی بهش نیاز دارم ...البته سرور ما JBOSSاست ..در واقع API که برای REGISTER کردن تو JNDI بکار میره ...

[javaphantom]

با سلام اگر کسی JNDIAPI استاندارد جاوا را میشناسه لطفا کمک کنه چون تو مرحله IMPLEMENT پروژه ام خیلی بهش نیاز دارم ...البته سرور ما JBOSSاست ..در واقع API که برای REGISTER کردن تو JNDI بکار میره ...

آفرین به شما که سرورتون JBoss. شما که سرورتون JBoss می دونستید که هم خود JBoss و هم خیلی از سایتها جواب شمارا دادن.


java.naming.factory.initial=org.jnp.interfaces.Nam ingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org. jnp.interfaces

[bahareh12]

متشکر اما من درخواست API استاندارد ای که به عنوان JNDIAPI استفاده میشدو کرده بودم اگه درست گفته باشم bind یکی از اونهاست...

[javaphantom]

متشکر اما من درخواست API استاندارد ای که به عنوان JNDIAPI استفاده میشدو کرده بودم اگه درست گفته باشم bind یکی از اونهاست...

JNDI ماله خود سان هست یعنی چی هی مگین استاندارد. من نمی فهمم.
دقیقا توی همین فروم همین بحث شد که گفتیم JNDI به چه دردی می خوره و برای چی هست.
اگر شما می خواهید از یک JVM به یک JVM دیگه دسترسی داشته باشید یعنی به Object هایی که در JVM دیگه هست یا اینکه می خواهید از JMS استفاده کنید از JNDI استفاده می کنید. بصورتی که اون object ممکنه در یک فلدر خاص که همان package هست و بانام مشخص که اسم Object هست شما از JNDI یک Context دارید که اون Context کارش اینه که اون Object مورد نظر رو براتون lookup کنه. حالا اینجا این سوال پیش می یاد
آیا شما دارید RMI کار می کنید؟ آیا دارید با EJB کار می کنید.؟ آیا شما دارید JMS کار می کنید؟
چی کار می خوای بکنی که هی مرتب می گی JNDI API استاندارد. من نمی دونم مگه شرکت دیگه ای هم JNDI داره که من خبر ندارم و استاندارد نیست؟

[mazdadoost]

سلام!
سوال درست میشه این: استفاده از JNDI API برای کار با JNDI مستقل از Provider!
از Binding تا Browsing تا ....
جوابش : یه کتاب!
موفق باشید.

[bahareh12]

شما درست میگید mazdadoost میدونم یه api اون همون bind دیگری lookup و اما در جواب دوست دیگمون باید بگم برای call کردن یه متدی که در component دیگه ای تعریف شده هم میتونیم از rmi استفاده کنیم که خیلی پر هزینه است پس مییایم در همون ابتدای کار یه کلاس entity تعریف کرده که یکسری api مورد نیاز component دیگمونو پیاده سازی میکند حال برای دسترسی به این متدها ابتدا در یک jndi که ساختاری مثل tree داره ذخیره یا همون bind کرده و با lookup کردن اسم کلاس entity میتوان به object اون دسترسی داشت و بعد component دیگمون مستقیما خود metodo میتونه call کنه .... درست گفتم ...

[javaphantom]

و اما در جواب دوست دیگمون باید بگم برای call کردن یه متدی که در component دیگه ای تعریف شده هم میتونیم از rmi استفاده کنیم که خیلی پر هزینه است
شما برای صدا کردن یا فرستادن یک message از یک component به component حالا می خواد method باشه یا یک فیلد، RMI نمی زنی می یایی instance می گیری. در صوردتی RMI می زنی که در دو JVM متفاوت باشند. یا با این فرض کار می کنی.
اما در مورد هزینه. آیا راه حل بهتری داری؟ RMI داستانش همینه. شما parameter می فرستی و در طرفی دیگر رو ی parameter های شما پردازش می شه و از اون طرف مقدار می گیری. برای اینکه مقدار هزینه رو کم کنی pattern هایی هستند که به شما کمک می کنه که هزینه پایین بیاد. حالا تا هزینه چی باشه.



پس مییایم در همون ابتدای کار یه کلاس entity تعریف کرده که یکسری api مورد نیاز component دیگمونو پیاده سازی میکند

اگر منظورت از Entity همان بحث Persistence ها باشه که در JPA وجود داره، بازم داستانش جداست بخاطر اینکه این بار parameter شما object ی هست که یک باید حتما Serializable باشه که در اون سمت De-Serialize می شه پس باید همان Entity یا همان Object رو اونورم داشته باشی، باز هم همون داستان هزینه هست. اینکه بیایی توی همین object یا بقول شما Entity متدود پیاده سازی کنی بعد بفرستی که دیگه من نظری ندارم، پس اصلا چرا داری Remote می زنی.

این متدها ابتدا در یک jndi که ساختاری مثل tree داره ذخیره یا همون bind کرده و با lookup کردن اسم کلاس entity میتوان به object اون دسترسی داشت و بعد component دیگمون مستقیما خود metodo میتونه call کنه .... درست گفتم ...
این مورد رو که اصلا نفهمیدم چی می شه ترجمش به فارسی. شاید داری کارکرد JNDI v رو توضیح می دین ،ولی عمل lookup موقعی صورت می گیره که شما Contextی داشته باشید که این Context بره محتویات یا بهتر بگم دنبال اون Object مورد نظر بگرده چه جوری از طریق JNDI یعنی نامی که شما به اون Object دادید. بعد عمل lookcup انجام می شه. البته شاید دارم اشتباه می کنم ولی من همیشه دیدم و خودمم این جوری عمل کردم.
الان شما توی همین سیستم عاملتون هم دارید یک جورایی JNDI کار می کنید.منظورم از لحاظ مفهومی. وقتی می گید c:\test\test.exe شما دارید یک مسیری رو طی می کنید که به مثلا object ی که مورد نظرتون هست و اون همان text.exe هست برسید.

توی پست اولتون شما اشاره به JBoss کردید. بعد سراغ JNDI رفتید. بعد توی پست بعدیتون یک سوال خیلی کلی تر مطرح کردید. منظورتون دقیقا چیه؟ این آخرین پست هم از Entity صحبت کردید آیا مشکل در JPA دارید؟ اگر دارید مستقیم RMI می نویسی پس JBoss اینجا چی کار می کنه؟

[bahareh12]

ببینید در واقع کل موارد مورد نیاز من در component diagram داشتن 2 تا component ..که اینها یه جوری به هم وابسته هستن ..به این صورت که با صدا کردن یک متد به هم وابسته میشن ..مثلا یکی از component ها وظیفه دادن یک شی مورد نیاز به component دیگه رو به عهده داره ...تا component اولی بتونه کار کنه ..حالا component اولی باید این تقاضا رو با call کردن یکی از متدهای implement شده در component دومی مطرح کنه ..پس بقول شما اینها توی دو ماشین جدا هستند پس از rmi استفاده میکنیم ..و اما مشکل من این است چطور میتونم بدون rmi مستقیما component اولی بتونه توی jndi متد لازمشو پیدا کنه ..