Object Class -Thread

Hai Respected Friend ,
I have one doubt regarding Object Class. for what purpose the Object class has some methods like Notify(),Notify All(),wait() though we are not using those methods except with Thread class.
why they are defined these methods in the Object Class ,why not in the Thread Class even though it is only useful with Thread Class.
Please give clear ans.
Thanks
Selvakumar

BigDaddyLoveHandles wrote:
malcolmmc wrote:
Actually, though these methods are useful only in a multi-threaded environment, no Thread objects are directly involved. What you need to specify isn't a thread object (the current thread is always the one affected) but the monitor, which can be any kind of Object.I would have been happy if they had defined a Lock class with wait and notify methods, because I prefer doing:
public class C {
private final Object lock = new Lock();
public void method() {
synchronized(lock) {...}
}to
public class C {
public synchronized void method() {
}In the second case, you have to contend with other code incorrectly calling wait/notify on an instance of C.
So I don't see the win in these being java.lang.Object methods, other than allowing you to create one less object -- what an efficiency win ;-)However, there are times when it makes sense to expose the lock. For instance Collections.synchronizedXxx.

Similar Messages

Why wait() is there in Object class why not in Thread class

why wait() is there in Object class why not in Thread class .
while we use wait() in the case of thread environment?
If there is any situation where we use it without using threads please mention with example. or link to that example..

839091 wrote:
The question still remain un-answered as the answers provided are not clear. Can anybody explain why wait(), notify() methods are available in Object class and not thread?What part of the answers given did you not understand?
Have you even tried writing any code that uses wait/notify and thought about how you'd write the same code if they existed only on Thread rather than on Object?
Have you studied the basics of Java's multithreading?
Do you know what a lock is?
Do you know what the synchronized keyword does?
Do you understand the relationship between synchronized and wait/notify?
If you can answer yes to these questions, then the reason that wait/notify exist on Object should be obvious. So, which of the above are "no"?

Thread Methods but in Object class, y?

Why wait, notify, notifyall methods are in object class instead of Thread class?

thechad wrote:
It's not clear to me why. Probably it's a historical artefact .. once it was in Object, it's hard to take it out.
You're question is a fair question it seems to me. Maybe someone will tell you there's a good reason.Yes, there is a very good reason and it's not a historical artifact.
wait / notify are used for locking in java. For instance, imagine you have a job queue, and you've got a whole bunch of worker threads that are getting jobs from it. What happens when the queue is empty and there are no more jobs? You want to wait for the queue to have more jobs. Then when a new job comes in, you want to notify any thread waiting that it can now proceed.
In fact, with reference to why isn't this just handled in thread, it is dangerous and wrong to call wait, notify or notifyall on a Thread object... Thread.join calls wait on the thread and thread death calls notifyAll, but API docs don't guarentee this so you should avoid these methods in a Thread object.

OBJECT Class

Hello people,
I am curious to know why the root class OBJECT, empty class, is a class why it was not created as an interface? What difference would make if it were an interface?
I would appreciate and reward points for good reasons.
Thanks & Regards,
Anand Patil

maghia wrote:
wait(), notify(), and notifyAll() methods are always used by Thread class objects.Whatever gave you this idea?
so.why the methods are available in Object class?Because they deal with locks, and every object has a lock.
[http://java.sun.com/docs/books/tutorial/essential/concurrency/]

Custom object classes and access rights

Hi,
I have added a few object classes to the NDS schema; objects
belonging to one of them should be able to authenticate against the
directory and retrieve some attributes. I managed the login part having
the class inherit from ndsLoginAttributes, but if I login as the object
itself, I can't retrieve any attributes. I can browse the entry (it's a
container), but all I get are DNs and objectclass attributes. Is there a
way to grant the object the right to retrieve its own attributes, or
some of them, through the Java LDAP interface?
Thanks,
Juan
jheguia
jheguia's Profile: http://forums.novell.com/member.php?userid=84575
View this thread: http://forums.novell.com/showthread.php?t=415769

Hello,
I found a solution which is *almost* the right one. Basically I
deleted the class and created it again with a default ACL:
X-NDS_ACL_TEMPLATES ( '2# subtree#[Self]#[All Attributes Rights]' )
This allows the object to do as it pleases with its own attributes. I'd
prefer it to be only able to read them, but I haven't found a syntax for
ACLs. Is there anything I can read to see how to fine tune the access
rights templates?
Thanks,
Juan
jheguia
jheguia's Profile: http://forums.novell.com/member.php?userid=84575
View this thread: http://forums.novell.com/showthread.php?t=415769

How to create object per thread

Hi everyone,
This is my problem. I want to have a static method. Inside of it I want to add an element into a List, let's say I want to track something by doing this. But I also want this List to have multiple copies depending on threads, which means for every call to this static method, I want to call the "add" method on different List objects depending which thread it is from.
Does it make sense? Do I need to have a thread pool to keep those thread references or something?
How about I use Thread.currentThread() to determine whether this call is from a different thread so that I create another List?
Thank you very much!
Edited by: feiya200 on Feb 26, 2008 10:31 PM

want to be perfect with singleton as why it is needed and how it works so see this by [email protected], Bijnor
For those who haven't heard of design patterns before, or who are familiar with the term but not its meaning, a design pattern is a template for software development. The purpose of the template is to define a particular behavior or technique that can be used as a building block for the construction of software - to solve universal problems that commonly face developers. Think of design code as a way of passing on some nifty piece of advice, just like your mother used to give. "Never wear your socks for more than one day" might be an old family adage, passed down from generation to generation. It's common sense solutions that are passed on to others. Consider a design pattern as a useful piece of advice for designing software.
Design patterns out of the way, let's look at the singleton. By now, you're probably wondering what a singleton is - isn't jargon terrible? A singleton is an object that cannot be instantiated. At first, that might seem counterintuitive - after all, we need an instance of an object before we can use it. Well yes a singleton can be created, but it can't be instantiated by developers - meaning that the singleton class has control over how it is created. The restriction on the singleton is that there can be only one instance of a singleton created by the Java Virtual Machine (JVM) - by prevent direct instantiation we can ensure that developers don't create a second copy.
So why would this be useful? Often in designing a system, we want to control how an object is used, and prevent others (ourselves included) from making copies of it or creating new instances. For example, a central configuration object that stores setup information should have one and one only instance - a global copy accessible from any part of the application, including any threads that are running. Creating a new configuration object and using it would be fairly useless, as other parts of the application might be looking at the old configuration object, and changes to application settings wouldn't always be acted upon. I'm sure you can think of a other situations where a singleton would be useful - perhaps you've even used one before without giving it a name. It's a common enough design criteria (not used everyday, but you'll come across it from time to time). The singleton pattern can be applied in any language, but since we're all Java programmers here (if you're not, shame!) let's look at how to implement the pattern using Java.
Preventing direct instantiation
We all know how objects are instantiated right? Maybe not everyone? Let's go through a quick refresher.
Objects are instantiated by using the new keyword. The new keyword allows you to create a new instance of an object, and to specify parameters to the class's constructor. You can specify no parameters, in which case the blank constructor (also known as the default constructor) is invoked. Constructors can have access modifiers, like public and private, which allow you to control which classes have access to a constructor. So to prevent direct instantiation, we create a private default constructor, so that other classes can't create a new instance.
We'll start with the class definition, for a SingletonObject class. Next, we provide a default constructor that is marked as private. No actual code needs to be written, but you're free to add some initialization code if you'd like.
public class SingletonObject
     private SingletonObject()
          // no code req'd
So far so good. But unless we add some further code, there'll be absolutely no way to use the class. We want to prevent direct instantiation, but we still need to allow a way to get a reference to an instance of the singleton object.
Getting an instance of the singleton
We need to provide an accessor method, that returns an instance of the SingletonObject class but doesn't allow more than one copy to be accessed. We can manually instantiate an object, but we need to keep a reference to the singleton so that subsequent calls to the accessor method can return the singleton (rather than creating a new one). To do this, provide a public static method called getSingletonObject(), and store a copy of the singleton in a private member variable.
public class SingletonObject
private SingletonObject()
// no code req'd
public static SingletonObject getSingletonObject()
if (ref == null)
// it's ok, we can call this constructor
ref = new SingletonObject();
return ref;
private static SingletonObject ref;
So far, so good. When first called, the getSingletonObject() method creates a singleton instance, assigns it to a member variable, and returns the singleton. Subsequent calls will return the same singleton, and all is well with the world. You could extend the functionality of the singleton object by adding new methods, to perform the types of tasks your singleton needs. So the singleton is done, right? Well almost.....
Preventing thread problems with your singleton
We need to make sure that threads calling the getSingletonObject() method don't cause problems, so it's advisable to mark the method as synchronized. This prevents two threads from calling the getSingletonObject() method at the same time. If one thread entered the method just after the other, you could end up calling the SingletonObject constructor twice and returning different values. To change the method, just add the synchronized keyword as follows to the method declaration :-
public static synchronized
     SingletonObject getSingletonObject()
Are we finished yet?
There, finished. A singleton object that guarantees one instance of the class, and never more than one. Right? Well.... not quite. Where there's a will, there's a way - it is still possible to evade all our defensive programming and create more than one instance of the singleton class defined above. Here's where most articles on singletons fall down, because they forget about cloning. Examine the following code snippet, which clones a singleton object.
public class Clone
     public static void main(String args[])
     throws Exception
     // Get a singleton
     SingletonObject obj =
     SingletonObject.getSingletonObject();
     // Buahahaha. Let's clone the object
     SingletonObject clone =
          (SingletonObject) obj.clone();
Okay, we're cheating a little here. There isn't a clone() method defined in SingletonObject, but there is in the java.lang.Object class which it is inherited from. By default, the clone() method is marked as protected, but if your SingletonObject extends another class that does support cloning, it is possible to violate the design principles of the singleton. So, to be absolutely positively 100% certain that a singleton really is a singleton, we must add a clone() method of our own, and throw a CloneNotSupportedException if anyone dares try!
Here's the final source code for a SingletonObject, which you can use as a template for your own singletons.
public class SingletonObject
private SingletonObject()
// no code req'd
public static SingletonObject getSingletonObject()
if (ref == null)
// it's ok, we can call this constructor
ref = new SingletonObject();
return ref;
public Object clone()
     throws CloneNotSupportedException
throw new CloneNotSupportedException();
// that'll teach 'em
private static SingletonObject ref;
Summary
A singleton is an class that can be instantiated once, and only once. This is a fairly unique property, but useful in a wide range of object designs. Creating an implementation of the singleton pattern is fairly straightforward - simple block off access to all constructors, provide a static method for getting an instance of the singleton, and prevent cloning.
What is a singleton class?
A: A class whose number of instances that can be instantiated is limited to one is called a singleton class. Thus, at any given time only one instance can exist, no more.
Q: Can you give me an example, where it is used?
A: The singleton design pattern is used whenever the design requires only one instance of a class. Some examples:
�     Application classes. There should only be one application class. (Note: Please bear in mind, MFC class 'CWinApp' is not implemented as a singleton class)
�     Logger classes. For logging purposes of an application there is usually one logger instance required.
Q: How could a singleton class be implemented?
A: There are several ways of creating a singleton class. The most simple approach is shown below:
Code:
class CMySingleton
public:
static CMySingleton& Instance()
static CMySingleton singleton;
return singleton;
// Other non-static member functions
private:
CMySingleton() {}; // Private constructor
CMySingleton(const CMySingleton&); // Prevent copy-construction
CMySingleton& operator=(const CMySingleton&); // Prevent assignment
Can I extend the singleton pattern to allow more than one instance?
A: The general purpose of the singleton design pattern is to limit the number of instances of a class to only one. However, the pattern can be extended by many ways to actually control the number of instances allowed. One way is shown below...
class CMyClass
private:
CMyClass() {} // Private Constructor
static int nCount; // Current number of instances
static int nMaxInstance; // Maximum number of instances
public:
~CMyClass(); // Public Destructor
static CMyClass* CreateInstance(); // Construct Indirectly
//Add whatever members you want
};

Reflection objects and thread safety

Hi,
I believe that I saw that Field and Method objects are thread-safe (i.e., can safely have methods called against a single object instance concurrently from multiple threads), but am having trouble finding such a description in the JDK javadocs static that fact.
I'm assuming that all thread-specific 'state' would be managed by the Object target passed to methods like invoke()/get()/set() and not on the actual Field and Method objects themselves. Ideally, i'd like to only have to look up fields and methods only once reflectively, and thereafter just use the same reflection object instances to access their target objects at runtime as a performance optimizations - possibly in different threads and at the same time - without having to pay the cost of looking it up again. I should be able to do that providing Method.invoke() is thread safe. Otherwise, i'd probably be forced to call Class.getMethod() to get a new Method object to use against each object instance, which would be more costly both from a memory standpoint (more Method objects) and a lookup-cost perspective.
Given that lots of existing performance-critical enterprise infrastructure code, such as OR database APIs, IoC frameworks and J2EE containers use reflection to decouple the generic code from any app specific code (from a compile time perspective) as an alternative to code generation, it's surprising that there's no obvious statement about thread safety in these classes. If I look at the source code for Method, it appears to be thread safe, but I can only get so far with this analysis, as the critical code in Method appears to be implemented using a class named 'sun.reflect.MethodAccessor', whose source I don't have access to.
I know it's possible to invoke a method against multiple objects by calling Method.invoke() against each of the target objects in question. However, there's no mention as to whether it's safe to use a single Method object instance to invoke a method against multiple target object instances at the same time (i.e., from different threads running in parallel). This would fail, for instance, if the Method object had data members that were used to communicate information between internal calls without any synchronization, as the values might be used by one thread while another was changing them.
Just to clarify (as i've seen some confusion in other forum discussions on this topic):
I completely understand that the thread safety of a target object's method (read, small 'm') is entirely dependent upon it's implementation and not the mechanism by which it's invoked - i.e., whether a method is invoked by an explicit compiled-in call against an instance of the target object in some Java source file, or indirectly via Method object-based reflection, is immaterial the the method's thread safety.
What i'm asking about is the thread safety of the Method.invoke() call itself (read, big 'M'). Same question wrt Field.get()/.set() as well. These calls should be thread-safe if they're stateless wrt the Method and Field object instances that they are invoked against.

In general, if a Java API is silent about multi-threading, it is intended to be thread-safe. See the javadoc for HashMap for an example of an explicit warning.
It is true that Java code can have bugs that show up only on unusual implementations of the Java memory model, such as relaxed memory model machines. Most (if not all) implementations of the JDK have been deployed principally on platforms with strong memory models. (Perhaps not coincidentally, those are also the machines that have market share.) There are even bugs found occasionally in the JDK core, so draw your own conclusions about the bug-tail of our software stack on systems with relaxed memory models!
One of the more likely bugs to run into on highly optimized systems is failure of timely initialization of non-final fields in objects which are shared in an unsynchronized manner. See http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#finalRight and related pages. JDK core programmers (at Sun, to my personal knowledge) take care not to write code with such bugs, but application programmers might.
And, yes, caching your own Method objects is a good idea, if only because their lookup is generally cumbersome and slow. If you are very performance sensitive, you'll end up generating bytecode "shim" between your callers and the desired target methods. I expect that the http://openjdk.java.net/projects/mlvm/ (an openjdk project we are just starting) will provide some relief for this; stay tuned.
Finally, since Method objects have no state to speak of (except their "accessible" bit, which is an ahead-of-time configuration), it would be really, really surprising if they could create a race condition of some sort. If you expect race conditions in formally stateless data structures, you are certifiably paranoid. (A normal state on some platforms, hopefully not on Java.)
For more information about method calls, including reflective methods, see my blog post: http://blogs.sun.com/jrose/entry/anatomy_of_a_call_site
Best wishes...

Why notify() and notifyall() is in Object class

pls help me
why notify() and notifyall() methods which are related to thread are define in Object class,instead of defining in Thread class

shouldn't be called on thread objects ever
at all (one of my pet peeves with Java)Why not? It would make a nice entry in the IOJJJ (International
Obfuscated Java Juggling Jamboree) if it existed ;-)First of all, sorry for my bad english. It's early here :)Nah, it's just a late a rainy Sunday afternoon here, so no problem ;-)
Second of all, the way that Thread is implemented, at least on
windows, it that calling Thread.join does a wait() on that thread object.
Thus, if you call notify() on a thread, you could actually be waking up
joined threads, which wouldn't be good. And if you called wait, you
could get woken up if the thread finishes which violates the contract of
wait and notify to some extent and also relies on an undocumented
feature.I take back my previous remark: it could not just be a nice little entry in
the IOJJJ, it would be a great entry in that contest! ;-)
kind regards,
Jos
ps. your example is the first example that clearly gives a reason for
spurious wakeups I've ever read; thanks; joined threads, I've got to
remember that example. <scribble, scribble, scribble/> done. ;-)

ObjectNotFoundException still does not show object class

I know I complained before but I want to emphasize it again
Without missing object class it is very very difficult to figure out whats
going on!!!
Please, please fix it!!!!
Exception in thread "main" javax.jdo.JDOUserException:
kodo.util.ObjectNotFoundException: The instance "NO2" does not exist in the
data store.[NO2]

Straight forward getObjectById causes this:
2422 TRACE [main] kodo.jdbc.SQL - <t 24347419, conn 30638546> [156 ms]
executing prepstmnt 3874616 SELECT t0.JDO_LOCK, t0.DESCRIPTION FROM
OBJECT_CLASS t0 WHERE t0.OBJECT_CLASS_CODE = ? [params=(String) xxx]
Exception in thread "main" kodo.util.ObjectNotFoundException: The instance
"xxx" does not exist in the data store.[xxx]
at
kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:2009)
at
kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1924)
at peacetech.nci.cs.jdo.CsJDOHelper.getObjectClass(CsJDOHelper.java:1626)
at peacetech.nci.cs.jdo.CsJDOHelper.getObjectClass(CsJDOHelper.java:1664)
at peacetech.nci.cs.LoadData.main(LoadData.java:224)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)
Another example:
Exception in thread "main" kodo.util.OptimisticVerificationException: The
instance "33.33" does not exist in the data store.[33.33]
at
kodo.runtime.AttachManager.getOptimisticVerificationException(AttachManager.java:184)
at
kodo.runtime.AttachManager.getOptimisticVerificationException(AttachManager.java:198)
at kodo.runtime.AttachManager.attachAll(AttachManager.java:79)
at
kodo.runtime.PersistenceManagerImpl.attachAll(PersistenceManagerImpl.java:4356)
at
peacetech.nci.cs.DetachTest.testNewObject(DetachTest.java:114)
at peacetech.nci.cs.DetachTest.main(DetachTest.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)

Why wait and notify kept in object class only

why wait and notify kept in object class only. is it maintain locks while doing wait and notify . please explain internals,

What do you mean in Object class "only"? If they're in Object, then they're in ALL classes.
They're in Object because any Object can serve as a lock.
For details of how to use them, see a Java threading tutorial such as http://java.sun.com/docs/books/tutorial/essential/threads/

Shared Objects for Threads

Hi,
Currently studying for SCJP exam and wondering is there a different between the following codes
public class Test extends Thread
static Object obj = new Object();
static int x, y;
public void run()
   synchronized(obj)
     for(;;)
      x++; y++; System.out.println(x+" "+y);
public static void main(String[] args)
   new Test().start();
   new Test().start();
}and
public class Test extends Thread
Object obj = new Object();
static int x, y;
public void run()
   synchronized(obj)
     for(;;)
      x++; y++; System.out.println(x+" "+y);
public static void main(String[] args)
   new Test().start();
   new Test().start();
In the first code example, is there a shared object between created threads and the second example, is their still a shared object between threads or is a new object created for each thread?
Cheers!

Hi,
In first case, you are acquiring lock on a static object that is of course shared (basic concept) by all instances(of Test). So, for any thread of any instance(of Test) to execute the synchronized block has to wait till any other thread of any other instance(of Test) comes out of synchronized block. It means, all the instances (of Test) are synchronized. In this scenario, you have infinite for loop within synchronized block and you are starting two threads. The thread which enters the synchronized block first will keep on executing and the other thread will never get chance to enter synchronized block.
In second case, as you are acquiring lock on an object, all the threads of a particular instance (of Test) will be synchronized. In this scenario, again you have infinite for loop within synchronized block and you are starting two threads on two different instances. Hence, both the threads will keep on executing in parallel.
I hope, you have already executed both the examples and observed output. And also hope that the above explanation will help you to understand the difference between two scenarios.
Note: Use System.out.println(Thread.currentThread().getName() + " " + x + " " + y); in your synchronized block to track which thread is printing the output.
Thanks,
Mrityunjoy

Why isn't Java's Object class abstract?

Why isn't java's Object class made as abstract class.

manoj.java wrote:
Why isn't java's Object class made as abstract class.The only good reason I can think of is that, back in the days prior to Java 5 and the incorporation of java.util.concurrent, bare Objects are useful as thread synchronization monitors (wait(), notify(), notifyAll()).
--p

Logging Java objects and threads. Application sampling.

I am using a laptop to run my application on. It uses windows XP and it is the only application running on that machine. I use TCP and serial port to communicate to other devices. My application is supposed to use up to 300M of memory but apparently it using much more than that. The laptop physical memory size is 512M. I am wondering if there is a way to sample my application periodically. What I mean by that is, after the applications runs I want to run at the same time kind of profiler that every, let us say, 10 minutes logs the number of objects created and what those objects are or what the current ones are. The number of threads running and what are their names. I want to know what is using all of this memory. The memory usage goes up to about 420M. As a result, the application throws out of memory exception. I believe I can get the number of threads running but do not know how to get their names. I need to know all of that so I would go into my code and see where it is happening and try to solve the problem. One of the ways I have in my mind now is to put a print out everywhere I create an object or thread, but that�s very expensive. Any hints or tips could be useful.
Thank you in advance.
P.S.:
I do not want to run a profiler such as JProfiler because the application is running live and I do not have access to it. I want to embed these logs into the application itself and rerun it on a live system.

As a first thought, I'm guessing that you're merely thinking that your program will not exceed 300 megabytes just based on the -Xmx300M command you may be passing your program. This is a max heap size, not the max footprint your program will take. Be aware that this can go beyond the scope of 300 MB....
Now, if you want very detailed information about processes, memory usage, etc, you might be able to keep track of it yourself, but if you want this information from a system-level sort of thing you will not get it, as one of the major points of Java is that it does not care about a lot of system specifics.
Now, if you're really interested in keeping track of threads, I don't see why you could not just write to a log file every time you spawn a new thread of a particular kind.

Object class name does not exist in IDM

Hi Team
We are process of Integrating GRC 10.1 to Enterprise Portal.Followed accordingly as per the SAP Note No. 1977781.
While running the Schema Job, we get a message Schema Imported Suxcessfully. While running the Job : GRAC_REPOSITORY_SYNC_JOB, the job
shows successful, but a Warning Message : User Adaptor Empty in SLG1 T.code.
I have checked the Path suffix,connectors,data source and all are maintained but no sure about this warning message.
Secondly,I tried for test creation of user on Portal via GRC 10.1.I am getting below error
"Object class name does not exist in IDM" Please see log below
Request gets closed stating Auto Provisioning failed.Please advice if someone has faced same issue and the steps taken to rectify it.
Thanks
Nitesh

Hi Nitesh,
We worked on this issue for quiet sometime with SAP to get this finally fixed You can check all below mentioned notes.
First Check:
Please check the Note: 1915763 - Error Provisioning from GRC 10 to SAP Portal while adding or removing a role in Change Account request type.
This Note says that if your LDAP set as data source is read-only in Portal, then you need to change it to Modifiable in order to allow create or change user belonging to LDAP.
We have set the UME correctly and no longer read-only. But our access requests still used to fail with the following messages.
"Object class name does not exist in IDM".
Second Check:
Kindly ensure the field mapping for portal is done in IMG settings properly.
If it is fine please check below note 2033714 - AC10.0: error in SGL1 "Object class name does not exist in IDM".
This note is only to check if you have made any mistake with your portal mapping and doesn't address the correct issue.
Third Check:
Finally after implementing SAP note 1941250 - UAM: Truncated parameters provisioned on changing users from Access Request
our issue got fixed.
Regards,
Madhu.

How to create custom attributes & object classes through ldif files in OID

Hi,
I have to create 4 attributes and one object class(custom) in OID. I want to creae these attributes and object class through LDIF file.
I tried creating an attribute through this command
ldapadd -p 389 -h localhost -D cn=orcladmin -w password -f D:/newattr.ldif
this ldif file contains inf. for creating a new attributes:
dn: cn=subschemasubentry
changetype: add
add: attributetypes
attributetypes: ( 1.2.3.4.5.6.10 NAME "xsUserType_new" DESC "User Type Definition" EQUALITY caseIgnoreMatch
SYNTAX "1.3.6.1.4.1.1466.115.121.1.15" )
I am getting error: Object class violation
Failed to find add in mandatory or optional attribute list.
Please help to find where I am going wrong...
Thanks.

Hi Ajay,
Thank you for the help. Now i am able to create both attributes and object classes in OID through Ldif files.
I was getting constraint violation error because (I think) I was not giving proper naming convection for attributes and object classes. For OID, there are certain Ldap naming conventions. They are as follows:
# X below is the enterprise number assigned by IANA
1.3.6.1.4.1.X.1 - assign to SNMP objects
1.3.6.1.4.1.X.2 - assign to LDAP objects
1.3.6.1.4.1.X.2.1 - assign to LDAP syntaxes
1.3.6.1.4.1.X.2.2 - assign to LDAP matchingrules
1.3.6.1.4.1.X.2.3 - assign to LDAP attributes
1.3.6.1.4.1.X.2.4 - assign to LDAP objectclasses
1.3.6.1.4.1.X.2.5 - assign to LDAP supported features
1.3.6.1.4.1.X.2.9 - assign to LDAP protocol mechanisms
1.3.6.1.4.1.X.2.10 - assign to LDAP controls
1.3.6.1.4.1.X.2.11 - assign to LDAP extended operations
By using these conventions for attributes and object class, I did got any error and they were created in OID.
Thanks a zillion.
Kalpana.

Object Class -Thread

Similar Messages

Maybe you are looking for